shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: Cracking off a release
Date Thu, 13 May 2010 19:29:43 GMT
+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.korhonen@gmail.com> wrote:
> On Thu, May 13, 2010 at 11:55 AM, Les Hazlewood <lhazlewood@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 <tauren@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.korhonen@gmail.com
>>>> wrote:
>>>
>>>> On Thu, May 13, 2010 at 10:43 AM, Craig L Russell
>>>> <craig.russell@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 <list@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.Russell@oracle.com
>>>> > P.S. A good JDO? O, Gasp!
>>>> >
>>>> >
>>>>
>>>
>>
>

Mime
View raw message