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

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

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?

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: August 1, 2003 11:47 AM
To: j=C3=BCrgen h=C3=B6ller [werk3AT];
spr...@li...;
rod...@in...
Subject: Re: [Springframework-developer] Current release plan - why
delay package renaming?


I wanted to play the devil's advocate and suggest that the package=20
renaming be done now instead of later.  I understand that the main issue =

is that it takes a while to do it through SourceForge in terms of=20
hanlding the CVS dirs on the server itself. However, the possibility of=20
just doing a checkin to the new location has already been mentioned and=20
would be very easy. Of course the history for files would still be=20
available at the old location.

Spring really seems to be getting a lot of momentum lately. I think it's =

really good stuff and most people who look at it seem to agree :-)   So=20
I think a package name now will potentially affect a _lot_ less people=20
than one later.  I know in our case, we have a pretty big project which=20
has started using Spring. In about a week, we need to do a big branch.=20
If both branches need to have Spring packages updated it will complicate =

the merge later. I think other people will have this sort of issue.

Another consideration is that 0.9.1 (as I understand it) introduces at=20
least a few non-backwards compatible changes. Doing the package rename=20
now would maybe make it possible for subsequent releases to remain=20
backwards compatible.

Regards,
Colin

j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>Everybody,
>
>As I just wrote in the reply to Alef's "PropertyEditors in JSPs" =
suggestion, we will very likely release a 0.9.2 at the end of August, =
with further polishing and enhancements.
>
>FYI, I'll be travelling to Australia for the whole of September, so I'd =
prefer to get 0.9.2 out before that, and our first org.springframework =
1.0 RC right after my return. Is a 1.0 RC1 target at the beginning of =
October fine for everybody? I hope it's not too late, but we will need =
the time anyway for documentation and all that stuff. 1.0 final could be =
possible in November then.
>
>BTW, we don't *need* to make SourceForge change our CVS directories to =
apply the package name change. We could also keep the current "main" =
module as it is, including all its version history, and introduce a new =
"main10" module with a fresh import of an org.springframework version. =
This would also make sense in terms of dead directories that a CVS =
update always traverses: There wouldn't be any then.
>
>Juergen
>
>
>-----Original Message-----
>From: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
>Sent: Wednesday, July 30, 2003 11:34 PM
>To: pr...@se...; Spring Developers
>Subject: Re: [Springframework-developer] Current release plan
>
>
>Hi Trevor,
>=20
>First of all, good questions resp. important ones indeed!
>=20
><quote>
>1. What still needs to be done for 0.9.1.  From that list, what is =
currently
>"assigned" to someone and what still needs help?
></quote>
>=20
>Not a lot, actually. It's mainly about polishing the Petclinic and =
Countries sample apps, and testing the current codebase in everyone's =
own projects. Everything should be assigned so far, except the latter of =
course :-)
>=20
>I'm currently polishing a lot of the source code. I've also added 2 new =
features that aren't committed yet but will be by the end of this week, =
namely Hibernate flush mode support on HibernateTemplate and =
HibernateInterceptor, and read-only transactions (suppressing Hibernate =
flush on the transaction level). Furthermore, I've refined =
TransactionInterceptor and MapTransactionAttributeSource a bit, =
supporting more configuration options then before.
>=20
><quote>
>2. Same as #1 but for the 1.0 release.
></quote>
>
>The first 1.0 RC will involve a package name change from =
com.interface21 to org.springframework. Besides that, there won't be a =
lot in terms of new features -maybe even less than from 0.9 to 0.9.1. =
Rod might already introduce some source-level attribute stuff to the AOP =
framework, but that isn't a requirement at all. Proper JMS and Web =
Service support are candidates too but can easily wait until 1.1.
>=20
><quote>
>3. What is the target time-frame for the 0.9.1 and 1.0 releases =
(obviously
>this is sketchy since it's "volunteer" work, but "gut guesses" - =
probably
>from Juergen :) - based on work left is what I'm hoping for.  The =
previous
>estimate was the 1.0RC1 by now.
></quote>
>=20
>0.9.1 should be out any day now. I encourage everyone to try it the =
current CVS version before the weekend. A release some time next week =
should really be achievable. We *need* to get out a follow-up release =
quickly, if just because of all the enhancements to the Hibernate =
support that have a good chance of getting adopted promptly. My =
Hibernate article in the community area and my postings to the Hibernate =
forum have already been discussing some of them for a while.
>
><quote>
>4. From Juergen's email which I referenced, it states "As far as I see, =
we
>don't need additional functionality for 1.0".  The main thing holding =
me
>back from adopting the current code base (I'm currently using a
>personally-modified version of 0.8) is the amount and frequency of =
changes
>to core functionality and the public api.  Some new features or minor =
bug
>fixes are ok/normal, but these sweeping changes are destructive to
>production code.  How close are we to finalizing the public api and the =
core
>code?  Is it likely that these major changes should be done for 0.9.1?
></quote>
>=20
>Maybe I'm promising too much, but I don't see any major changes on the =
horizon. The introduction of the new DTD was probably the biggest change =
in the last few months, everything else was just about slight changes to =
the public API. I agree that we need stable APIs though to allow =
production apps to rely on them without *any* hassle. 0.9.1 should be as =
stable as can be in that respect, besides the package name change for =
1.0 RC which should just involve a search-and-replace.
>
><quote>
>To expand on my fourth question with a recommendation (hopefully it =
makes
>sense to everyone).  If possible we should finalize the public api for
>version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
>development without fear of incompatibilities in the next couple =
months. (...)
></quote>
>=20
>As I indicated above, I fully agree. We've been changing our apps at =
werk3AT quite often too, it would be fine it that wouldn't be necessary =
anymore as soon as possible. And I'd really like to get you on board =
again, in terms of working with a current Spring version :-)
>=20
>Regards,
>Juergen
>N=18HS^=E9=9A=8A[){([Zzn=E8=A5=B4=044D=D7=ACw%=D8=A76i=17l=11&x+ljwEjzz0=
=0E'Z=C9=A9z{^0v\=13bJ=DB=9DDN=1Bm=DA=B2=DE=B5brK&
>?=C6=B4]4M=DA=BD=DD=8AZ=DE=B7NM5J=07jg=1Dzx%R=DA=99(G^hlq=07zm?X(=1E~zwX=
b?=07jg=1Dz
>N=18?HS^?=E9=9A=8A[)?{(??[?Z?z??n=E8=A5=B4=04?4D?=D7=AC?w%?=D8=A7?6?i=17=
???l=11?&???x?+??ljwE??????j??zz0=0E?'?????Z=C9=A9?z{^??0?v?\=13???b??J=DB=
=9D??DN=1Bm??=DA=B2?=DE=B5?brK???&?
>??=C6=B4?]4?M=DA=BD?=DD=8A????Z??=DE=B7N??M???5J??=07?jg???=1Dz??????x%?=
?R?????=DA=99?(?G^??h????l???q??=07?z?m????X???(??=1E~??zw??X?????b??????=
=07?jg???=1Dz??
>




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer