Thanks for explaining the reasoning. Again, it doesn't matter to me which way you go, I'm just excited to see a release!
Tauren On Thu, May 13, 2010 at 12:29 PM, Les Hazlewood <lhazlew...@apache.org>wrote: > +1 > > My opinion is that I'd like to only deal with RC releases for 1.1 or > later if the dev team feels like it. > > Les > > On Thu, May 13, 2010 at 12:22 PM, Kalle Korhonen > <kalle.o.korho...@gmail.com> wrote: > > On Thu, May 13, 2010 at 11:55 AM, Les Hazlewood <lhazlew...@apache.org> > wrote: > >> I think it's mostly for perception. We've waited a _long_ time to > >> release 1.0 and I think a 1.0.0-RC1 release would feel like "oh here > >> we go - 1.0 is _still_ not ready?". We've worked a lot on stability > >> such that I don't foresee many bugs cropping up, so it shouldn't be a > >> big deal to go from 1.0.0 to 1.0.X quickly if necessary. > >> Also, I don't know that Maven's release plugin works well with > >> suffixes after the point version - it auto-increments point numbers or > >> minor revision numbers automatically based on the previous number. I > >> think the RC stuff would kind of screw that up, no? > > > > Maven's release plugin would work with any version number. However, > > versioning Maven artifacts currently "works best" with 3-digit > > numbering scheme. It guarantees the right automatic resolution for > > example in a case where version ranges are used. Not entirely my > > opinion only, but RCs are a way to cope with the imperfections of > > doing blind releases - the final artifact is built only once and then > > released. If there are issues that could not have been foreseen, you > > have spin off a new release to fix them. Now, the staged release fixes > > this problem by allowing a limited number of users to examine the > > final artifact before it's being release to the wild. In practice, the > > right process depends on the scope of changes, the size of the > > existing user base, your confidence in the test suite etc. Maven, for > > example uses both RCs and staged releases since the user base is so > > large that any little issue would generate a lot of flak. While > > there's been a few interface changes lately, Shiro has enjoyed(?) a > > long sink-in time with the snapshots releases, so going with plain > > 1.0.0 release is the right choice in my opinion. > > > > Kalle > > > > > >> On Thu, May 13, 2010 at 11:38 AM, Tauren Mills <tau...@tauren.com> > wrote: > >>> I'm curious why you wouldn't do release candidates, such as 1.0.0-RC1, > >>> 1.0.0-RC2 and have 1.0.0 GA be the final accepted release. This isn't a > >>> complaint, do it however you wish, I'm just interested to know the > >>> reasoning. > >>> > >>> Tauren > >>> > >>> > >>> On Thu, May 13, 2010 at 11:22 AM, Kalle Korhonen < > kalle.o.korho...@gmail.com > >>>> wrote: > >>> > >>>> On Thu, May 13, 2010 at 10:43 AM, Craig L Russell > >>>> <craig.russ...@oracle.com> wrote: > >>>> > Great to hear that you're ready to "crack off" a release. You need > to > >>>> > decide: > >>>> > Is this a final release or some early access or beta thing? > >>>> > What tools will you use to create the release artifacts? > >>>> > Will you release binaries or just sources (most Java projects > release > >>>> both > >>>> > binary and source). > >>>> > Who is going to be the release manager? > >>>> > >>>> I'll take this. Assuming Les is fine it, I'll be the release manager. > >>>> This is a 1.0.0 GA release. We are going to release with Maven using > >>>> the staged release process so we'll have some time to test the final > >>>> artifact before its being released publicly and while it's being vote > >>>> upon. If we find blockers, we'll abandon the release and do a new > >>>> point release - 1.0.1 etc. until the staged release is accepted. While > >>>> I haven't cut any Apache releases before, I'm fairly familiar with > >>>> Tapestry's releases which use the same process and I've done staged > >>>> releases with Maven/Nexus before. > >>>> > >>>> Kalle > >>>> > >>>> > >>>> > After you know what to release and who is going to create the > release > >>>> > artifacts, you can proceed to step 2: creating the release > artifacts. > >>>> There > >>>> > are many examples of releases from incubation that you should > probably > >>>> study > >>>> > and then volunteer to cut the release(s). > >>>> > > >>>> > The first release of a podling is normally reviewed by a small > number of > >>>> > really dedicated volunteers who find many trivial-sounding problems > that > >>>> in > >>>> > fact are very important. But whoever volunteers to be the release > manager > >>>> > should expect between two and five attempts before passing muster > for an > >>>> > official Apache incubating release. > >>>> > > >>>> > Craig > >>>> > > >>>> > On May 13, 2010, at 9:47 AM, Les Hazlewood wrote: > >>>> > > >>>> >> We're working on it! :) > >>>> >> > >>>> >> Seriously though - I think we can be code complete today. After > that > >>>> >> is finished, I was going to ping the list to ask the Mentors how we > go > >>>> >> about starting the voting process. Since we might be able to start > >>>> >> this tomorrow, could you fill us in a bit on how this works? > >>>> >> > >>>> >> Thanks! > >>>> >> > >>>> >> Les > >>>> >> > >>>> >> On Thu, May 13, 2010 at 8:28 AM, Alan D. Cabrera < > l...@toolazydogs.com> > >>>> >> wrote: > >>>> >>> > >>>> >>> :) > >>>> >>> > >>>> >>> We've been at this for quite some time. I've been approached by > people > >>>> >>> wondering when this is going to happen. > >>>> >>> > >>>> >>> I think that a release would be a good idea. Thoughts? > >>>> >>> > >>>> >>> > >>>> >>> Regards, > >>>> >>> Alan > >>>> >>> > >>>> >>> > >>>> > > >>>> > Craig L Russell > >>>> > Architect, Oracle > >>>> > http://db.apache.org/jdo > >>>> > 408 276-5638 mailto:craig.russ...@oracle.com > >>>> > P.S. A good JDO? O, Gasp! > >>>> > > >>>> > > >>>> > >>> > >> > > >
