Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] Maintenance Release Target Milestones
I'm down with the Ganymede x.y.1 idea, but I prefer Ganymede SR1 and SR2 to x.y.1 and x.y.2, since it better aligns with the train. True too, the SR2 build may include x.y.3, not .2, if an interim extra build was done (eg., GMF).
That said I'll wait for Ed to weigh in when he gets back from his travels abroad. 

Nick

Christian W. Damus wrote:

Hi, Eike,
I agree. I would be happiest if Bugzilla had separate "Target Version" and "Target Milestone" fields, but alas, it does not. Of course, in that case, a "Ganymede x.y.2" target would be a target version, and not a milestone, but that would be fine.
I thought that the problem was in the proliferation of version *numbers* in the target milestones, so that we had, for example, 2.4.1/1.2.1/1.0.1 all referring to the same maintenance release of different EMF components, where a single "Ganymede x.y.1" would suffice for the lot.
However, now I am stuck with a bunch of bugs that were targeted for maintenance releases and are now targeted to "Past," and I have no sensible alternative in the current list of milestones. I just want to get back to conveying the same information in my bugs as they did last week.
"Ganymede x.y.1" etc. is not a great solution, but it fits the current database schema and it would actually work. 

If anyone has a cleaner solution, please let me know!

Thanks,

Christian

On 24-Nov-08, at 2:04 PM, Eike Stepper wrote:


Christian,
I always thought a clean solution would include separate target versions and generic target milestones. But I believe that this would require a broader discussion, if possible at all... 

Cheers
/Eike

----
http://thegordian.blogspot.com


Christian W. Damus schrieb:

Hi, all,

I have a follow-up problem on the subject of target milestones.
I see that we have SR1 and SR2 milestones, now, which I suppose are meant for the targeting of bugs into the maintenance releases. However, this raises some questions: 

    * how do I indicate which release stream
      (Europa/Ganymede/Galileo) the maintenance fix is targeted at?
       It doesn't make sense to use the flags because they are for
      planning, and these fixes aren't planned.  (besides, only
      Galileo has a flag)
    * my components have maintenance releases that line up with the
      train SR1 and SR2, but also more releases in between.  For
      example, I had a 1.2.1 release before 1.2.2 which corresponded
      with SR2.  We could add, say, SR3 and SR4 milestones, but the
      "SR" terminology suggests a correspondence with the train
      timetable
Can we, perhaps, add generic milestones as follows, to solve both of these issues? 

    * Ganymede x.y.1
    * Ganymede x.y.2
    * Ganymede x.y.3
    * Galileo x.y.1
    * Galileo x.y.2
    * Galileo x.y.3
I'm not sure that the SR1 and SR2 milestones will be useful. Perhaps they could then be deleted. 

What do other EMF committers think of this?

Thanks,

Christian

--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@xxxxxxxxxxxxx <mailto:cdamus@xxxxxxxxxxxxx>



------------------------------------------------------------------------

_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev


_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx <mailto:emf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/emf-dev


--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@xxxxxxxxxxxxx <mailto:cdamus@xxxxxxxxxxxxx>



------------------------------------------------------------------------

_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev


--
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash CBI

Back to the top