Menu
▾
▴
Re: [Springframework-developer] Current release plan - why delay package renaming?
|
From: Rod J. <rod...@in...> - 2003-08-03 07:09:51
|
I've been thinking it over last night and I can see major marketing advantages in a 1.0 name. (For TSS article etc.) So I'm inclined to agree with Trevors suggestion as to Eclipse-stype "milestones". 1.0M1 sounds good. I agree that "beta" is almost meaningless. We should decide on how many milestones before RC1. I think only 2. Regards, Rod ----- Original Message ----- From: "Trevor Cook" <pr...@se...> To: <spr...@li...> Sent: Saturday, August 02, 2003 5:05 PM Subject: RE: [Springframework-developer] Current release plan - why delay package renaming? 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). 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ürgen höller [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. 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. 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. Juergen -----Ursprngliche Nachricht----- Von: Rod Johnson [mailto:rod...@in...] Gesendet: Sa 02.08.2003 10:00 An: j rgen hller [werk3AT]; Trevor Cook; spr...@li... Cc: Betreff: Re: [Springframework-developer] Current release plan - why delay package renaming? > 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. We all seem agreed. > 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. 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. spring10. > 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. 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. Regards, Rod +^ [){([ ky k{ [@H ;"" nv) ZE h (gq ??Z h?j?i^'Z z{^?0?v\bJ ? w brO_ o lkM5M4 ?y j ?; }7M _ *kx ?zZ)zXX*kx ? ?zZ)z l .a w i +-( ~ { b ?+-w k?x ? ?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 ------------------------------------------------------- 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 |
