I wasn't aware of that decision. It sounds like a semantics issue to me. Instead of RC1 you just label it 1.x.x right? Then you make a decision later about whether or not its "release worthy?"
My point about doing a release build that you may or may not promote as an official release still stands. So if you want to call it 1.0.0 and maybe not release until 1.0.3 or something that sounds acceptable. I am not sure if three builds (1.0.1, 1.0.2, 1.0.3) is less confusing than (1.0.0 RC1, 1.0.0 RC2, 1.0.0). People may wonder what happened to the "interim" release numbers. A few questions. For these interim builds that don't get released officially. I assume these builds aren't in the apache archive or Maven repository right? You just make them in the nightly dir or something for people to evaluate? Also, for bug reporting do you recommend a verison number for each interim release? sean On 11/28/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 11/27/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I agree that release candidates can be helpful with checking packaging > > errors (and testing against TCK which is not an issue in this case.) > > That's true, Sean, but what you may not know is that over a year ago, > we had a very long discussion on dev@ about the release process. In > the end, we decided that Apache Struts would *not* issue distributions > that were tagged with arbitrary qualifiers like "beta" or "release > candidate". Each and every non-nightly distribution would be a > milestone with it's own unique version number expressed as three > integers (major.minor.milestone). Witness the Struts 1.2.x series for > this process in action. > > We worked very hard to educate people as to the "milestone-only" > release scheme, and I am concerned that calling anything a "release > candidate" again will only cause confusion. > > It is my feeling that the so-called 1.0.0-rc1 should be tagged as the > 1.0.0 distribution, and the subsequent distribution should be 1.0.1. > If 1.0.1 becomes a GA release, that would be great. If it doesn't, > then 1.0.2 can be next up to bat. > > -Ted. > > > > > I'm +1 for getting some kind of "official" release soon. I think more > > users will feel comfortable jumping in once Shale is released. I > > think we should quickly shift our attention to the multiple dialog > > issue though because that is a severe limitation that users will > > complain about. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
