Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] FW: Changing Eclipse BIRT Indigo Version Number to BIRT 3.7

The release number of the platform should not matter to other adopters.  I know people like to have things all lined up, but the reality is that the version of the platform is just a number.  For instance, we have some bundles that have version numbers > 3.7.0 in our 3.7 stream builds. Orbit bundles that we ship as part of the platform don't follow OSGi/Eclipse versioning schemes.  So they don't have 3.7 versions.   What the Eclipse 3.7 version does signify to our consumers is that since the 3.6.x releases, we haven't broken any API.

By Eclipse versioning guidelines, we signify to our consumers that we broke  API by incrementing the major version.  The proposed BIRT move from 2.6 to 3.7 is very confusing.  This signifies to me that BIRT has broken API from the previous release.  And for good measure, the minor version was incremented.   This type of change doesn't make sense according to the guidelines

You consumers shouldn't expect that versions of multiple projects to match. This isn't the case for any simultaneous release.   It's better to think of the release name Helios, Indigo etc. instead of arbitrary numbers :-)


From:        Wenfeng Li <wli@xxxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        01/28/2011 04:25 PM
Subject:        Re: [cross-project-issues-dev] FW: Changing Eclipse BIRT        Indigo        Version        Number to BIRT 3.7
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

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.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Friday, January 28, 2011 1:10 PM
Cross project issues
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, 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 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>
"cross-project-issues-dev@xxxxxxxxxxx" <cross-project-issues-dev@xxxxxxxxxxx>
01/28/2011 04:30 AM
[cross-project-issues-dev] FW: Changing Eclipse BIRT Indigo Version        Number to BIRT 3.7
Sent by:        

Hi All,

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 stream projects.

Please let us know if you have any questions.



birt-dev-bounces@xxxxxxxxxxx [
mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul Clenahan
127 9:39
[birt-dev] Changing Eclipse BIRT Indigo Version Number to BIRT 3.7


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.

Let us know if you have any questions.


Paul Clenahan


cross-project-issues-dev mailing list
cross-project-issues-dev mailing list

Back to the top