incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eugen Paraschiv <hanrisel...@gmail.com>
Subject Re: Moving some minor issues from 0.0.2 to 0.0.1 to get them committed before the release?
Date Wed, 02 Mar 2011 22:08:48 GMT
The stable branch is a good idea in my mind as well. The only downside of it
is that it would introduce complexity in the release process, especially
thinking of maven-release-plugin. This may not be an issue once we start
having more release experience, but seeing how this is our first release, my
thinking was that moving an issue back is simpler for now. But that all
depends on the person doing the release. Hope this makes sense. Thanks.

On Thu, Mar 3, 2011 at 12:03 AM, Chapuis Bertil <bchapuis@agimem.com> wrote:

> Good point. Personally I think that the release should not block the
> development of 0.0.2. It seems that the solution proposed in [1] could make
> sense in our case. if there is no objection I propose to create a stable
> branch with the current state of the trunk and to start applying the
> patches
> for 0.0.2 on the trunk. The 0.0.1 release will be made from the stable
> branch.
>
> [1] -
> http://lsimons.wordpress.com/2010/02/19/using-long-lived-stable-branches/
>
>
>
> On 2 March 2011 22:45, Eugen Paraschiv <hanriseldon@gmail.com> wrote:
>
> > Hi,
> > I have a few patches on 0.0.2 issues that are probably ready to commit
> (or
> > at least review). I had previously moved them to 0.0.2 in order to clear
> up
> > 0.0.1 and move the release forward (which it is). But seeing how this is
> > our
> > first release and it will probably take a few more days to finish (my own
> > guess), I wanted to ask about the timeframe of the release process, and
> if
> > it makes sense to move back and quickly get committed some minor 0.0.2
> > issues.
> > Thanks for any feedback.
> > Eugen.
> >
>
>
>
> --
> Bertil Chapuis
> Agimem Sàrl
> http://www.agimem.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message