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

[Trevor C. <pr...@se...>]

+1 for 1.0 beta1 - This is all just "marketing stuff" (we could as =
easily jump to v7 like slackware did - =
http://www.slackware.com/faq/do_faq.php?faq=3Dgeneral#0 - :) ).  Those =
"in the know" follow the actual progress of the features and code, those =
outside use the version number to determine whether to use the project.  =
While the code is "not perfect", I feel it's good enough to start =
projects on which will be deployed around the end of the year (4-6 =
months) considering the current state of the code, the rapid development =
by active contributors, and the current plans for a release version.  I =
think the "beta" tag presents a more accurate image to those less =
familiar with Spring that it isn't done, but it's good enough to start =
using in the "real world".

+1 to new module (I'd lean to sticking with a "main#" rather than =
"spring#") - After hearing recent comments about the ease with which we =
can do it ourselves (no help required from Sourceforge) and the extra =
history it will provide, it seems like the simpler and smarter path.

+1 to delaying JMS / Web Services - Most of the features slated for 1.0 =
appear to be enhancements to things Spring already does well (like Tiles =
being added to our solid MVC core).  We should focus on polishing, =
fixing, and enhancing our current features, rather than just adding =
more.  This has the added benefit that by the time we hit 1.0 some good =
projects may already have been created to address these, and we can =
"stay with our strength" and simply write Spring wrappers around those =
projects (similiar to our "adoption" of Hibernate).

That's a lot of +1's.  Is this an election year?  :)

Trevor D. Cook



-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: August 1, 2003 6:33 PM
To: Trevor Cook; spr...@li...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?


Hi everybody,
=20
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.
=20
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.
=20
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.
=20
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.
=20
Regarding release notes for changes since 0.9: I'll try to collect them =
from the mailing list, there is quite a number of them actually.
=20
I'd also like to make up a concrete release plan for the follow-up, be =
it 0.9.2 or 1.0 beta2, with an approximate timeframe - probably =
beginning of September. Obvious candidates are:
=20
- ResultSets from stored procedures;
- Tiles integration;
- advanced PropertyEditor support for JSPs;
- compatibility testing;
- polished sample apps;
- very important: documentation and tutorials.
=20
I guess that stuff like metadata attributes driving AOP interceptors =
will be beyond that timeframe. But we don't need to cram everything into =
this follow-up: 1.0 RC1 in early October will be a fine milestone too. =
It would generally be good to publish one release per month towards 1.0.
=20
Finally, regarding the scope of 1.0 final: I still vote for delaying JMS =
and Web Services support until 1.1, to be able to stabilize and polish =
the current features as much as possible for 1.0. The same applies to =
stuff like TopLink support or JSR-168 Portlets. We can still decide to =
focus on certain features earlier if current needs arise, of course.
=20
Regards,
Juergen
=20
=20

	-----Ursprngliche Nachricht-----=20
	Von: Trevor Cook [mailto:pr...@se...]=20
	Gesendet: Fr 01.08.2003 18:09=20
	An: spr...@li...=20
	Cc:=20
	Betreff: RE: [Springframework-developer] Current release plan - why =
delay package renaming?
=09
=09

	Changing it now would be better for me, but I can work with either name =
(my main problem was the public api which a search/replace won't solve =
:) ).  I would vote +1 to do it now, but I don't know the reasons for =
the delay to RC1.  To those who know (Juergen/Rod?), is there a =
technical reason for the delay, or just the release plan?
=09
	Trevor D. Cook