[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emf-dev] Bugzilla Milestones for Maintenance Release
|
Hey Christian,
In theory, we have an opportunity to align with Eclipse. Ganymede is Eclipse 3.4, so everybody is version 3.4. Interestingly, GEF has always remained aligned with Eclipse.
This breaks however when a new component X wants to make a 1.0 while the next moon is 3.5. And what about when component Y wants to do a 2.0?
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GMF / Modeling Tools
Phone: 613-270-4613
![Inactive hide details for "Christian W. Damus" ---05/30/2008 04:52:07 PM---Hi, Ed, I guess one problem that we have is that we]()
"Christian W. Damus" ---05/30/2008 04:52:07 PM---Hi, Ed, I guess one problem that we have is that we don't have uniformity in
![]()
From: | ![]()
"Christian W. Damus" <cdamus@xxxxxxxxxxxxx> |
![]()
To: | ![]()
Eclipse Modelling Framework <emf-dev@xxxxxxxxxxx> |
![]()
Date: | ![]()
05/30/2008 04:52 PM |
![]()
Subject: | ![]()
Re: [emf-dev] Bugzilla Milestones for Maintenance Release |
Hi, Ed,
I guess one problem that we have is that we don't have uniformity in release numbers.
Is that something that we should change? It needn't have any correlation to plug-in/feature version numbers, but then that would be confusing.
cW
On Fri, 2008-05-30 at 16:40 -0400, Ed Merks wrote:
Nick,
I never use these darned things anyway, but somehow this doesn't have much appeal... There's a lot to be said for uniformity across projects...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
![Inactive hide details for Nick Boldt/Toronto/IBM@IBMCA]()
Nick Boldt/Toronto/IBM@IBMCA
Nick Boldt/Toronto/IBM@IBMCA
Sent by: emf-dev-bounces@xxxxxxxxxxx
05/30/2008 04:31 PM
Please respond to Eclipse Modelling Framework <emf-dev@xxxxxxxxxxx> |
|
|
For something completely different, instead of 1.2.0M5, 1.0.0RC2, and
2.4.0M7 (lots of duplicate targets because of disparate versions every
year), and all the .0, .1, .2 variations), how about something more
coordinated release friendly, and chronological?
200709 Ganymede M2
...
200805 Ganymede M7
200805 Ganymede RC1
...
200806 Ganymede Release
200807 IO M2
...
200809 Ganymede Update 1
...
200902 IO M5
200902 Ganymede Update 2
...
This would also be cleaner than what MDT has as far as its "1.1" project
release which includes ocl 1.2, uml2 2.2, uml2 tools 0.8, xsd 2.4, etc.
But as with most things, I'm easily swayed by the majority rule. :)
Thoughts?
(BTW, that 1.0.1 is historical because of QTV's Callisto release-- it
wasn't added recently for advanced scheduling.)
Anthony Hunter wrote:
>
> Hi again,
>
> I strongly believe we should be following the platform (all other
> eclipse components) by putting the actual targeted milestone and not
> dot X.
>
> When you run a Bugzilla query, you get the target milestone in the
> list. I frequently run queries based on target milestone. Going
> forward we need to click on every bug and read the comment to see what
> release the bug was fixed in?
>
> Perhaps a better approach is getting the older releases removed?
>
> That being said, you guys own EMF and are best suited to know what
> works for you.
>
> Cheers...
> Anthony
> --
> Anthony Hunter mailto:anthonyh@xxxxxxxxxx
> Software Development Manager: Eclipse Open Source Components
> IBM Rational Software: Aurora / GMF / Modeling Tools
> Phone: 613-270-4613
>
>
> Inactive hide details for "Christian W. Damus" ---05/30/2008 01:52:28
> PM---Hi, Anthony, You will always know when a bug was act"Christian W.
> Damus" ---05/30/2008 01:52:28 PM---Hi, Anthony, You will always know
> when a bug was actually fixed because a comment is
>
>
> From:
> "Christian W. Damus" <cdamus@xxxxxxxxxxxxx>
>
> To:
> Eclipse Modelling Framework <emf-dev@xxxxxxxxxxx>
>
> Date:
> 05/30/2008 01:52 PM
>
> Subject:
> Re: [emf-dev] Bugzilla Milestones for Maintenance Release
>
> ------------------------------------------------------------------------
>
>
>
> Hi, Anthony,
>
> You will always know when a bug was actually fixed because a comment
> is appended when the fix is available in a build (verified), which
> indicates the build ID, including the release number.
>
> Does that help?
>
> I'm just thinking that, as there are going to be a considerable number
> of components in EMF, with different version numbers, the number of
> milestone entries will become rather large.
>
> Cheers,
>
> Christian
>
> On Fri, 2008-05-30 at 13:26 -0400, Anthony Hunter wrote:
>
> Hi Christian,
>
> -1 on the 2.4.x, In 2009, how will we know if the bug was
> fixed in 2.4.1 or 2.4.2 ?
>
> It is safe to use 2.4.1 and 2.4.2 as a start to align with
> our two scheduled Ganymede maintenance releases.
>
> Cheers...
> Anthony
> --
> Anthony Hunter _mailto:anthonyh@xxxxxx.com_
> Software Development Manager: Eclipse Open Source Components
> IBM Rational Software: Aurora / GMF / Modeling Tools
> Phone: 613-270-4613
>
>
> Inactive hide details for Christian"Christian W. Damus"
> ---05/30/2008 12:47:54 PM---Hi, I am finding myself
> needing to schedule a bug for my Transaction 1.2
>
> From:
> "Christian W. Damus" <cdamus@xxxxxxxxxxxxx>
>
> To:
> emf-dev@xxxxxxxxxxx
>
> Date:
> 05/30/2008 12:47 PM
>
> Subject:
> [emf-dev] Bugzilla Milestones for Maintenance Release
>
>
> ------------------------------------------------------------------------
>
>
>
>
> Hi,
>
> I am finding myself needing to schedule a bug for my
> Transaction 1.2 maintenance release, and that raises some
> practical questions.
>
> I see that the EMF core component does not yet have any
> milestone(s) created for 2.4 maintenance, but I see that
> the 2.2 maintenance stream has 2.2.1 and 2.2.3 entries.
> Curiously, there is nothing for the 2.3 branch (not even
> the 2.3.0 release).
>
> So, going forward with the various components that we have
> at various version numbers, I propose that each
> maintenance branch be identified by a single *.x milestone
> (e.g., 1.2.x, 2.4.x). This has the benefit of being
> distinct from the next release (2.5, 1.3) and avoiding
> clutter in the drop-down list. I don't think it's
> necessary to identify individual releases on the same
> maintenance branch, because they happen in serial order
> and any bug scheduled on the maintenance branch would just
> go into the next maintenance release.
>
> What do y'all think? If we are agreed, I can volunteer to
> create the following milestones:
>
> - 2.4.x for Core
> - 1.2.x for QTV
>
> (the CDO, Net4J, and Teneo components already have a 1.0.1
> waiting and ready).
>
> Thanks,
>
> Christian
> ------------------------------------------------------------------------
>
>
> Christian W. Damus
> Senior Software Developer, _Zeligsoft Inc._
> <http://www.zeligsoft.com/>
> Component Lead, Eclipse _MDT OCL_
> <http://www.eclipse.org/modeling/mdt/?project=ocl> and
> _EMF-QTV_
> <http://www.eclipse.org/modeling/emf/?project=transaction>
>
> _______________________________________________
> emf-dev mailing list
> emf-dev@eclipse.org_
> __https://dev.eclipse.org/mailman/listinfo/emf-dev_
>
>
>
> _______________________________________________
> emf-dev mailing list
> _emf-dev@eclipse.org_ <mailto:emf-dev@xxxxxxxxxxx>
> _https://dev.eclipse.org/mailman/listinfo/emf-dev_
> ------------------------------------------------------------------------
>
> Christian W. Damus
> Senior Software Developer, _Zeligsoft Inc._
> <http://www.zeligsoft.com/>
> Component Lead, Eclipse _MDT OCL_
> <http://www.eclipse.org/modeling/mdt/?project=ocl> and
> _EMF-QTV_
> <http://www.eclipse.org/modeling/emf/?project=transaction>
>
> _______________________________________________
> emf-dev mailing list
> emf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emf-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> emf-dev mailing list
> emf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emf-dev
>
--
Nick Boldt :: Release Engineer, IBM Toronto Lab
Eclipse Modeling :: http://www.eclipse.org/modeling
http://wiki.eclipse.org/index.php/User:Nickb
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
