While each project can document the mapping between its release
number to the simultaneous release name, adopters do need to read the “manuals”
if they want to assemble an environment that is not already packaged. There
seems no way around it. I will propose to BIRT community to use 3.0
instead of 3.7. Thanks.
Wenfeng
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff
McAffer
Sent: Friday, January 28, 2011 2:16 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] FW: Changing Eclipse BIRT Indigo
Version Number to BIRT 3.7
Certainly that is one choice that would work in the broad
Eclipse context. From an individual project point of view however, what
if you release more often than the simultaneous release? Indigo is just one
interesting point in time where everyone got together. I would hesitate to
bind *your* version identifier to that of anyone else (platform, simultaneous
release, ...). Presumably the new BIRT will work with Eclipse 4.1 as well?
Concretely I suggest that BIRT be 3.0 and on the appropriate
web pages you indicate that 3.0 is the release that is in Indigo.
Jeff
On 2011-01-28, at 4:02 PM, Wenfeng Li wrote:
Hmm, does this mean the solution is to name all our download
package and update site with “Indigo”? The
issue we want to address is at the project download/packaging level, so the
bundle release number is not necessary required to change.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Friday, January 28,
2011 1:55 PM
To: Cross project issues
Subject: Re:
[cross-project-issues-dev] FW: Changing Eclipse BIRT Indigo Version Number to
BIRT 3.7
IMHO this is the wrong direction. The platform project
will release versions with numbers that reflect the semantics of what happened
from the last release. If you change BIRT API again and the platform
doesn't, what will you do? In fact, in Indigo the platform team will
release both 4.1 and 3.7. In short, this approach is not sustainable.
If you take a close look at the elements of the Platform you
will see many (most) that are not 3.7.x. In fact, looking at recent 3.*
stream builds for the classic SDK you will only see a relative handful of 3.7.*
bundles.
To a certain extent this is one of the values that the
simultaneous release provides. One consistent, named release of function
that is meant to go together.
If the last release of BIRT was 2.7 and this release is not
backward compatible then it should be 3.0.
On 2011-01-28, at 3:23 PM, Wenfeng Li wrote:
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
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 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.
From: Xiaoying Gu <xgu@xxxxxxxxxxx>
To: "cross-project-issues-dev@xxxxxxxxxxx"
<cross-project-issues-dev@xxxxxxxxxxx>
Date: 01/28/2011 04:30 AM
Subject: [cross-project-issues-dev]
FW: Changing Eclipse BIRT Indigo Version Number to
BIRT 3.7
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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.
Thanks,
Xiaoying
From: birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul Clenahan
Sent: 2011年1月27日 9:39
To: birt-dev@xxxxxxxxxxx
Subject: [birt-dev] Changing
Eclipse BIRT Indigo Version Number to BIRT 3.7
Team,
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.
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.
Regards,
Paul
Clenahan
BIRT
PMC
_______________________________________________
cross-project-issues-dev mailing
list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
