[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emf-dev] Bugzilla Milestones for Maintenance Release
|
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
