I wonder how many other WTP adopters also have the same preference.
I know most adopters (all except you?
:) would have a fit if we changed our bundle versions that way. Features
... I'm not so sure. I know of less breaking dependencies there ... but,
there could be depending on how they defined relationships, and I am pretty
sure most would not like it. So we in WTP decided long ago to "follow
the rules" when it comes to bundles and feature versions.
I suspect we all could do a better job
of labeling and discussing high level things with release names, rather
than numbers. For example, the Platform, a year or two ago, started to
use the yearly release name (Helios, Indigo) in their splash screen, rather
then the platform version number. I thought that was great.
I agree its confusing, but I think the
current versioning rules make the best of a bad, inherently complicated
situation. If you'd like to remind your self how it used to be even worse,
you can go back and read the 128 comments in a bug from 2005 bug
99393 (On the PRETTY BAD practice
of NOT VERSIONING Eclipse) That bug was mostly about version numbers
not changing enough, but it did give rise to our current rules.
I suggest if anyone sees a webpage or
something where the yearly name would serve better than a project's main
version number then that would be a valid bug. I was going to mention that
perhaps a central place to list project versions in yearly releases, but
I see there is already such a central
list for Helios, though I do not
know how that list is created, and it appears a bit out of date and inconsistent.
I'm also not sure what problem is being
solved ... one for end users? Or release engineers? ... but perhaps the
problem would be reduced or broken into smaller pieces, and bugs opened
to make some improvements, though I suspect it'll always be confusing to
Wenfeng Li <wli@xxxxxxxxxxx>
Cross project issues
01/28/2011 04:27 PM
FW: Changing Eclipse BIRT Indigo
to BIRT 3.7
There is indeed change in
the BIRT runtime API that require clients of BIRT runtime to make a change
(while only a simple change, It is still a change).
The reason of matching the
platform release number is to meet request from BIRT adopters.
Actually, as an WTP adopter,
It will help us as well if WTP also change its release number to
follow platforms. I wonder how many other WTP adopters also have
the same preference.
On Behalf Of David M Williams
Sent: Friday, January 28, 2011 1:10 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] FW: Changing Eclipse BIRT Indigo
Version Number to BIRT 3.7
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 "2.7"?
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
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,
Thanks again, for keep us all informed.
FW: Changing Eclipse BIRT Indigo Version Number
to BIRT 3.7
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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
The changes will include feature version change and plugin version change,
which might affect download stream projects.
Please let us know if you have any questions.
From: birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx]
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.