Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Next version after 3.0

As an adopter, I vote that version increments should be based on level of API breakage, or huge overarching changes in underlying implementation.

Small bug-fixes, marking APIs as @deprecated but keeping them active, etc, should be a tiny point release (3.1.1, for example). Adding new APIs with a tiny number of breakages should be a full point release (3.1, 3.2, etc). Full version releases should be for huge architectural rewrites, direction shifts, or reorganizations.

At the very least, there should always be one point release between major versions for bug fixes, even if most of the focus will be on the next full version release.

Another idea is how heavily the pre-requisites change. Are you using features from the platform's new full version that are unavailable in previous versions? If yes, then you might bump the version up to a full one just because. Are you targeting a dependencies point-only increase? Then you might just bump up a point (unless WTP itself had a huge change.) Using new APIs from dependencies shouldn't be done without good reason, knowing it will bump up the version number.

- Rob Stryker

Raev, Kaloyan wrote:
Hi, let me add to the mess, too :-)

Since there is no strong logic in the WTP version numbers, I would suggest
that we align them to the ones of the Eclipse Platform. This means that the
next WTP version should be 3.5 or 4.0, depending on the next version number
of the Platform. EMF and GEF are doing well with this concept. And I think
this approach reduces the confusion to the end user.
About the "December" releases... Well, we have 6 Milestones during the
yearly release. The December release is actually M3. It is a matter of good
planning and quality to make our milestones as good as an official release.
I don't think we have to implicate version numbers here.

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Konstantin Komissarchik
Sent: Friday, January 25, 2008 9:41 PM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Next version after 3.0

I would have to second that. While in theory, version numbers are
meaningless, in practice they can send very specific messages. One of
the problems that I see with incrementing the first digit yearly is what
would happen if we actually wanted to do a WTP equivalent to "Eclipse
4.0". That is something that is significantly different from current
code base (large amount of new functionality and/or good amount of api

- Konstantin

PS: I don't think it's very likely that we would do a mid-year
non-maintenance release. Most of team is busy on maintenance work for
prior version through late fall. There wouldn't be anything interesting
to put into a mid-year release.

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On Behalf Of David Carver
Sent: Friday, January 25, 2008 10:58 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Next version after 3.0

David M Williams wrote:
I'm probably in the minority, but I think every year should be a full increment. Why? Why not? To me, these numbers are nearly meaningless so why not assign the meaning "the yearly release".
Actually, I would disagree that they are meaningless. Typically, incrementing the major version number means you are breaking public API compatiblity for some reason or making something not backwards compatible. If no major breakage or redesign is planned (i.e. redesigning SSE or something like that), I think it sends a better message to just do a point release.

Perception is a strange beast, it's all based on ones view, as an adopter I'd feel more comfortable with a point release, only a major release if something major is breaking.

wtp-dev mailing list

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.
wtp-dev mailing list

wtp-dev mailing list

Back to the top