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.
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David
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
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"?
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
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
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.).
for keep us all informed.
Xiaoying Gu <xgu@xxxxxxxxxxx>
01/28/2011 04:30 AM
[cross-project-issues-dev] FW: Changing Eclipse BIRT
Indigo Version Number to BIRT 3.7
project is planning to change the main release number from 4.0 to 3.7 for
that the Indigo M5 is quite close, we will not make this change for M5.
changes will include feature version change and plugin version change, which
might affect download stream projects.
let us know if you have any questions.
birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul
Subject: [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 �C 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.
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.
cross-project-issues-dev mailing list