RE: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Ian Skerrett wrote on 08/11/2006 08:59:23 PM:

> You are correct I did not understand the original proposal.  
If I 
> understand, you are suggesting that each project involved in the 
> Europa release would call their release Europa, ex. Eclipse Europa
> Release, BIRT Europa Release, Web Tools Europa Release,.  This
would
> essentially become a common identifier for all projects that 
> participated in the release but not trying to have the same version
> number across all projects.  Do I understand correctly?  This
sounds
> like a reasonable idea. 

That's exactly what I meant.  I can't emphasize
enough that the plugin and feature version numbers will *never* go away
or be wholely replaced by names.  I was just suggesting that we adopt
the name chosen by the community (Europa) as the overall name for that
particular release, rather than "3.3".  All projects and
plugins would continue to have version numbers under the covers, which
you would find, for example, in the Help > About dialog.

> 1) For people on the outside, I think sequential
release numbers 
> make it easier for them to understand what is the latest and 
> greatest.   Remember we would be generating a new name each year,
so
> people on the outside would be forced to keep up with what is the
> latest.  If we were like Microsoft and only released every 5-7
years
> this is certainly less of a concern. 

This is a good point that was raised in the architecture
meeting. The release train naming convention causes this problem. Two answers
that were raised: the feature numbers of the various projects will still
be there and if someone digs down they'll find it (for example under help
> about).  The other answer was, "If we're cool enough, it
won't matter".  I.e., if Eclipse has enough brand awareness then
enough people will know that "Callisto" comes before "Europa".
 

> 2) Third party plug-in providers need to identify
which version of 
> the Eclipse SDK they are compatible.  Maybe it is just me but
I 
> think saying XYZ plug-in is compatible with Eclipse 3.1, 3.2, 4.0
> etc is just easier to understand than XYZ plug-in is compatible with
> Callisto, Europa, next-Jupiter-moon-name-that-Bjorn-likes, etc.  


Absolutely, plug-ins and plug-in authors will certainly
work at the level of version numbers.  At this level the version numbers
have strong semantic value that could never be replaced by a non-numeric
name.  At the marketing level, I suspect third party plugin providers
already say to their customers, "Here is the version of our plugin
that is compatible with Callisto".

> 3) I think for a global audience, sequential
numbers is much easier 
> to translate and ensure we don’t violate/confuse people in the 
> translations.   As you pointed out even Europa was not really
well 
> received in Europe.  Calling something the Europa Fall and Europa
> Spring release might be a bit confusing in Australia.

Yes, but again this is a problem with the release
train name.  I agree the release train maintenance releases need better
names than Fall and Spring updates.

> 4) How you would name the actual zip file and
then further 
> maintenance releases.   For example, say some project created
their 
> final build and it was made available for download, I assume the zip
> file would have a name, maybe XYZProject-Europa.zip.  Then a
really 
> urgent critical bug came in and the release needed to be cracked 
> open and tweaked.   I am assuming the file name would have to
> change.   Would this essentially start to create a version name
> based on the package number?

File names would still use the feature version numbers.
I.e., if the version number of the Eclipse SDK feature is 3.3, then the
filename of the SDK download will remain, for example, Eclipse-SDK-3.3-win32.zip.

> 5) In general I really do believe people expect
and are sensitized 
> to having a release numbers.  If the SDK does have one, it will
just
> create confusion.  
>  
> As a wild idea, why not just separate the release
number from the 
> plug-in version.   We are going into the sixth year for the SDK,
so 
> why not just call it Eclipse 6.  Next year call the release Eclipse
> 7.   We could also have all the projects identify their Europa
> release. For example, WTP could be the WTP 2.0 Europa Release or 
> BIRT 2.2 Europa Release.  

Incidentally this would line us up exactly with the
JDK approach - if you download the JDK release called "J2SE 5",
and type "java -version" at the command line you get something
like "1.5.0_05-b03". I.e., they have decoupled the release name
from the language and virtual machine version numbers that have stricter
semantic value.

>  
> I do realize a lot of these things are subjective
and just opinions 
> but I think that is what you were asking for.  Hopefully this
will 
> help generate some discussion.

This thread has certainly spawned some interesting
(and humourous) discussions of version names. I think most will agree that
we're not going to start picking new names for the June 2007 release.  The
only intent here was to start making more prominent use of the name that
the community had already chosen.  It may be worth revisiting the
naming discussion when it comes time to pick a name for the release after
Europa.  

John

> From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-
> bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
> Sent: November 8, 2006 1:59 PM
> To: General development mailing list of the Eclipse project.
> Cc: 'Bjorn Freeman-Benson'
> Subject: RE: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006
>  
> 
> I think you might have misunderstood what I meant.  I wasn't
> suggesting that the Eclipse SDK would be called Callisto or Europa.
> I'm saying the release of the Eclipse SDK that ships next June would
> be called "The Europa release of Eclipse", just as there
will be a 
> "Europa release of Web Tools", "Europa release of Data
Tools", etc. 
> In other words, it *is* the name of the event, not the name of the
> technology.  The number "3.3" has lost any useful meaning
in 
> describing release event because it is no longer tied to the version
> numbers of the plugins and features in that release.   
> 
> Our maintenance releases are a good example of the problem.  We
have
> started working on the "3.2.2" maintenance release, but
if you 
> download this release and look at the plugins, you will see plugins
> numbered 3.2.0, 3.2.1, 3.2.2, 3.2.3, and many other numbers. So "3.
> 2.2" is not really a useful description of that release. Meanwhile,
> the rest of the world just wants to know when the next Callisto 
> update will arrive, they don't care what number is attached.  The
> same may become true of the release next June. If we decided that
it
> was important to add some API in a maintenance release before next
> June (as some projects have already done), we would have to increase
> some plugin version numbers to "3.4" for the June 2007 release.
 
> Thus Eclipse "3.3" would have some "3.3" and some
"3.4" features 
> inside it, which is just confusing for everyone.  To give another
> example, some plugins within the SDK may want to release more often
> - for example new releases of the compiler to coincide with Java 
> language releases, or new releases of Equinox to coincide with new
> OSGi specification releases. They would be free to do so as long as
> they also produce a release next June to join the Europa train. Thus
> you could imagine Eclipse SDK 3.5 containing version 3.6 of the Java
> tools and version 3.8 of the OSGi implementation, etc. Just as a 
> single version number cannot be applied to all projects shipping in
> the Europa release, there is no single version number that applies
> to all the components of the Eclipse SDK. 
> 
> To give a final thought from a marketing perspective: if we follow
> our own version numbering guidelines, and we never make breaking API
> changes in the future, we will forever be stuck with "3.x"
releases 
> of the SDK.  How exciting does Eclipse 3.8 sound? It sounds like
yet
> another series of minor changes to Eclipse version 3.  In reality,
> we believe each annual release has lots of exciting new features and
> technology, which is undershadowed by the "point release"
label 
> attached to it. 
> 
> John 
> 
> "Ian Skerrett" <ian.skerrett@xxxxxxxxxxx> 
> Sent by: eclipse-dev-bounces@xxxxxxxxxxx 
> 08/11/2006 12:41 PM 
> 
> Please respond to
> "General development mailing list of the Eclipse project."
<eclipse-
> dev@xxxxxxxxxxx>
> 
> To
> 
> "'General development mailing list of the Eclipse project.'"
> <eclipse-dev@xxxxxxxxxxx> 
> 
> cc
> 
> "'Bjorn Freeman-Benson'" <bjorn.freeman-benson@xxxxxxxxxxx>

> 
> Subject
> 
> RE: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006
> 
> John, 
>   
> I am not sure this is such a great idea.   First, Callisto and
> Europa are names that were created to reference a specific event,
> the release of multiple Eclipse projects.   It was not intended
to 
> identify a particular thing, project or technology.   Second,
I don’
> t think we want people to start calling the SDK,  Europa or 
> Callisto, since this will start to weaken the Eclipse name.  
In 
> fact, we are actively trying to stop using the Callisto name, so if
> the SDK started having this in the splash screen it would be counter
> to this approach. 
>   
> My preference is that you stick with version numbers to identify the
> SDK releases. 
>   
> Ian 
>   
>   
>   
>  
> 
> 
> From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-
> bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
> Sent: November 8, 2006 12:04 PM
> To: General development mailing list of the Eclipse project.
> Subject: Re: [eclipse-dev] Planning Meeting Notes - Nov 8, 2006 
>   
> 
> For those interested, the outcome of the discussion topic below is
> that we generally agree that adopting the Eclipse Foundation release
> naming is a good idea. I..e, begin referring to the next release of
> the Eclipse SDK as "Europa" rather than "3.3".
This has absolutely 
> no impact on the mechanics and version numbers of plugins and 
> features. The most obvious place this will likely show up is in the
> Eclipse splash screen.  This actually brings us more in line
with 
> the rest of the world, who have consistently referred to the 
> previous release as "Callisto" while we kept calling it
"3.2". 
> Discussion and comments from the community appreciated... 
> 
> (And yes, we already know this will confuse some Austrians... https:
> //bugs.eclipse.org/bugs/show_bug.cgi?id=147754#c10) 
> 
> John 
> 
> Mike Wilson/Ottawa/IBM@IBMCA 
> Sent by: eclipse-dev-bounces@xxxxxxxxxxx 
> 08/11/2006 08:57 AM 
>  
> 
> Please respond to
> "General development mailing list of the Eclipse project."
<eclipse-
> dev@xxxxxxxxxxx>
> 
> To eclipse-dev@xxxxxxxxxxx 
> 
> Subject [eclipse-dev] Planning Meeting Notes - Nov 8, 2006
> 
> ------------ 
> Discussion 
> ------------ 
> 
> Workspace: 
> - Plugin version numbers no longer match the version we attach to
the 
> release overall: Eclipse 3.2.2, Eclipse 3.3., etc.  Should we
re-brand 
> our releases to avoid using these numbers? I.e., change our plans,
> documentation, splash screen, etc, to refer to "Eclipse Callisto
Fall 
> Update" or "Eclipse Europa" rather than numbers?  This
would harmonize 
> with other Eclipse projects, and prevent the desire to "cheat"
and align 
> our feature and plugin versions with a release number that has lost
its 
> original meaning.