You are at 2.6.x for Helios, right? How'd
the heck you get to 4.0 anyway!? :) I'm not a (direct) consumer of
BIRT, so doesn't matter to me directly ... but from a Simultaneous Release
point of view, we all should be following the guidelines in http://wiki.eclipse.org/Version_Numbering,
right? Is that not known? Or are there reasons for an exception in your
case? I am not asking for the purpose of giving you or your project a hard
time, but just wanted to know if there is a way we as a community can help?
And now that you've settled on 3.7,
let me ask ... are you sure? Are there really breaking API changes that
justify the increase in 'major' field from 2.6 to 3.7? If not, why not
Especially for plugins. If adopters
specified version ranges for their birt bundle prereqs as is recommended
and commonly done, such as [2.6,3.0), then they they will automatically
be broken by the change in versioning, If there are indeed breaking API
or behavior changes then that's "good" ... but, if there are
no breaking changes, then that's "bad" as it requires change
in source for no reason. Adopters are often frustrated by having to make
such "meaningless" changes.
It is a little less harmful to make
major-field changes in feature versions, and I have seen cases where people
follow the "versioning rules" strictly for bundles, but may loosen
up the rules for features; if that helps.
Of course, you may have very good reasons
for making these "major changes" and if so, that's great, thanks
for keeping us all well informed. But, if your reason is just that you
want to "match the platform" ... well, that's hard if not impossible
to do, and IMHO not a good reason to breaking your adopters. But, as I
said ... I am not an adopter, so just take this as advise, not a complaint.
FYI for all: one implication of feature
version numbering "going down" is that our previous-milestone-composites
will have to be removed ... so sounds like M6 common repo will be only
M6 (no composite pointers to M5, M4, etc.).
Thanks again, for keep us all informed.
Xiaoying Gu <xgu@xxxxxxxxxxx>
01/28/2011 04:30 AM
FW: Changing Eclipse BIRT Indigo Version Number
to BIRT 3.7
BIRT project is planning
to change the main release number from 4.0 to 3.7 for Indigo release.
Considering that the Indigo
M5 is quite close, we will not make this change for M5.
The changes will include
feature version change and plugin version change, which might affect download
Please let us know if you
have any questions.
On Behalf Of Paul Clenahan
Subject: [birt-dev] Changing Eclipse BIRT Indigo Version Number to
For the BIRT project’s Indigo release
in June of this year, our plan continues to be to match the BIRT version
number with the Eclipse Platform version number used for Indigo. Going
forward, this will make it easier for everyone to remember which version
of BIRT is designed to work with which version of the Platform. And with
Indigo being the 8th major release of the BIRT project, there is no downside
with updating the release number to match the Platform release.
At the outset of the Indigo project, it
was an open question whether Indigo would be Eclipse 3.7 or 4.0 – so as
a short term measure, we adopted BIRT 4.0 as the working release number
for BIRT Indigo. Now that the Indigo release will be designated Eclipse
3.7, we plan to update BIRT Indigo to use the BIRT 3.7 designation.
So, consider this a heads-up that in the
next week or so you will see the designation of the BIRT release we are
working on for June change from BIRT 4.0 to BIRT 3.7.