[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Bundle major versions and project major release
|
Hi John/all,
Thanks all (Thomas, Jeff, John, all) for the comments...I think I'm
getting to some greater clarity.
John Arthorne wrote:
I would go further and suggest three part version numbers aren't even
really needed as your project release marketing number. You could just
call your releases "Helios", "Helios SR1", etc, or even something like
"June 2009". I think for a project like ECF in particular, where there
are many different unrelated components at different levels of
maturity, giving a single "number" to describe the release doesn't add
much value.
Yes...I agree that having a single number to describe the release
doesn't add a lot of value from a technical perspective, but on the flip
side is the issue of positive attention (call it marketing) that is
associated with a major version number change. That is, to get adoption
and grow the community, ECF has to use its available resources make
people aware that there are new things available, and promote them.
Part of this is getting attention, press interest, etc....and having one
moniker (either a 'named' release or a new version) to refer to 'all the
new and cool stuff in ECF' is aided by having a distinctive handle to
refer to (e.g. ECF 3.0 vs ECF 2.0).
Like I said...I do agree that this is not a lot of technical value...but
especially for relatively newer projects (i.e. newer than the
platform/IDE), and projects that don't have their own marketing
resources...the attention, marketing, promotion from a major release (as
opposed to minor or service) is an important concern.
As an aside...we can/could have a distinct named release...e.g. ECF
'Titan'...but I have a feeling this would/could be very confusing for
the simultaneous release...e.g. what are we... 'Helios', 'Titan',
'Homer', 4.0, something else? Anyway, this potential for name
collision/interference is what has kept me away from those directions.
We've seen this transition from three part numbers to more opaque
release identifiers in other places, such as Java itself dropping
1.x.y in favour of "one part" version numbers (Java 6, Java 7, etc).
Dropping the second and third digit takes away the perception that
there is a strong semantic value to the number change, giving you the
freedom to just increment every year. In this vein, maybe you could
just do "ECF 4", "ECF 5", etc.
Yeah, I've been thinking of that.
If you do stick with a three part release number, there are several of
examples of projects shipping "minor" releases that contain bundles
with major version increases. For example the Eclipse Platform shipped
version 3.5, containing org.eclipse.ecf version 3.0, but Eclipse
Platform 3.4 contained org.eclipse.ecf version 2.0.
Right...forgot about that one :).
Thanks.
Scott
