RE: [Springframework-developer] Current release plan - why delay package renaming?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

As far as "main" vs "spring", my main concern is consistency.  I'd =
change my vote to "spring#" IF we can rename/delete the current main, =
but as Juergen says, having multiple names is really confusing (I've =
been bitten by this myself).

Now that I've conceded victory for the module name to my opponents, I =
would like to continue campaigning for 1.0-x . :)

For the "1.0 beta" vs "0.9.1" the major sticking point appears to be =
"feature freeze".  Maybe beta is the wrong term, and we should consider =
"stable build".  To me this makes more sense (even more sense than =
"beta" now since that term seems to be vastly abused IMO). =20

I tend to follow the release style followed by eclipse (see =
http://www.eclipse.org/downloads/index.php).  Basically the version is =
the current version being worked towards, and the number is indicitive =
of the current status.  They basically progress from "stable builds" to =
"release cantidates" to "release".  Their naming for the stable builds =
is usually "3.0M2" or 2.0M5" with the prefix (3.0 / 2.0) as the version =
worked towards, M signifying its not a release, and the suffix (2 / 5) =
indicating which stable build.  Features and bug-fixes are continually =
added during stable builds, feature freeze isn't implemented until the =
first RC.  The progression is generally:

1.0M1
1.0M2
1.0M3
1.0RC1
1.0RC2
1.0R	2.0M1
1.1	2.0M2
1.2	...
...

Another point is how we will handle future releases. I know I'm getting =
way ahead of the project, but our current naming structure will dictate =
the future naming (or we'll have mass confusion).  When we are working =
on Spring 2.0, how will we name releases?  Is 1.6 a bug fix to 1.5, or a =
prerelease of features for 2.0?  I think that if the version is always =
the "release version being worked towards" we'll have less confusion.  I =
think this extends even to the 1.1 name Rod was mentioning (for JMS, =
etc.) since that brings up questions on whether it is a 1.0 bug fix or =
new features.

I would appreciate any feedback on these comments.  Specifically, if you =
prefer to stay with the "0.9.1" and "1.1" naming style, how does a =
newcomer know which is the latest release (without scouring the mailing =
lists), which is bug-fixed release versions, and which are development =
releases?  I'm sure there are other ways than what I'm proposing, it =
just appears to make the most sense of the methods I've encountered.

Trevor D. Cook

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: August 2, 2003 11:23 AM
To: Rod Johnson; Trevor Cook;
spr...@li...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?

So it's currently 2:1 in terms of "1.0 beta" vs "0.9.1". Like Trevor, I =
also thought of the marketing effect. On the other hand there are really =
some features left to add for 1.0, and I can understand the argument =
that we should avoid the impression of a feature freeze. Reconsidering =
this, it's probably better to stay with 0.9.x for the time being.
=20
There is a consistency issue with the name of the new module for the =
org.springframework version: be it "spring1" or "spring10" - both =
suggest that they contain the 1.0 sources.  Releasing a 0.9.1 based on =
such a module could lead to confusion. I don't have a perfect =
alternative though: Maybe "spring" (analogous to "hibernate") without =
explicit version number, with the option to use "spring2" for a 2.0 =
source tree. After all, the root of the problem is probably the name =
"main" for our current sources. No matter if we choose "spring", =
"spring1", or "spring10" - having a "main" alongside can cause =
confusion.
=20
Regarding the version number in the module name: We should try to decide =
when to create a new module upfront. Hibernate has "hibernate" for 1.x =
(1.0, 1.1, 1.2), and a new "hibernate2" module for 2.x (2.0 and the =
upcoming 2.1). So if our 1.1 release will basically be a 1.0 follow-up =
snapshot with a larger number of new features than the last 1.0.x, it =
would make sense to keep 1.x in the same module. As this is very likely, =
I consider it safe to assume that we will create a new module for 2.0 =
but not earlier. Therefore, a "spring" or "spring1" module name is =
appopriate - I suggest a "spring" module, as argumented in the previous =
paragraph.
=20
Juergen
=20

	-----Ursprngliche Nachricht-----=20
	Von: Rod Johnson [mailto:rod...@in...]=20
	Gesendet: Sa 02.08.2003 10:00=20
	An: j rgen hller [werk3AT]; Trevor Cook; =
spr...@li...=20
	Cc:=20
	Betreff: Re: [Springframework-developer] Current release plan - why =
delay package renaming?
=09
=09

	> Wow, there seems to be an overwhelming consensus to change the =
package
	names now. Well, then let there be org.springframework :-) The =
reasoning
	behind delaying this to 1.0 RC initially was to keep consistency for =
current
	users. On the other hand, there's the strong argument of a growing user
	base: An early change will affect less people.
=09
	We all seem agreed.
=09
	> Of course we can still keep 0.9.1 as next version number. Calling our
	current status 1.0 beta1 wouldn't be absurd though, just look at at the
	eager release policies of Jakarta or Hibernate. Note that for any =
subsequent
	version like 2.0 there will only be the beta/RC-option. So, opinion =
poll:
	stay with 0.9.1 or eagerly move to 1.0 beta1 now? I'm inclined to go =
for the
	latter.
=09
	I agree with Thomas. 1.0 beta 1 implies a feature freeze to me, and I =
don't
	think we're there yet. The pace of change is certainly slowing and =
hopefully
	future changes will be backward-compatible, but I think we need 0.9.1 =
before
	1.0 beta 1.
	>
	> BTW, what does everybody think regarding a new CVS module
	"main1"/"main10", or "spring1"/"spring10", or the like? The Hibernate =
team
	works with a "hibernate2" module currently, having the 1.0 tree in
	"hibernate", so creating a new module seems appropriate to me.
=09
	spring10.
=09
	> To avoid unnecessary further delays, I urge everybody to commit all
	dangling changes. If we agree on the module and its name, I'd like to =
create
	it on Monday and import a clean org.springframework version. Then we =
should
	test that with current apps, and if everything succeeds, we should be =
able
	to publish the release at the end of the week.
=09
	I'm done until we release, although I would like to be able to get back =
into
	the codebase no later than the end of the week.
=09
	Regards,
	Rod
=09
=09
=09

                     +=12=17^ [){([ ky k{ [@H =11;"" nv)
ZE h =13(gq ??Z h?j?i^=0E'Z z{^?0?v\=13bJ =11?   w brO_ o lkM5M4  ?y j =
?; }7M=7F _                 *kx=1F  ?zZ)zXX*kx=1F? ?zZ)z l .a=1Ew i =
+-(=1E~ { b ?+-w k?x=1F? ?zZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18/07/2003