incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chapuis Bertil <bchap...@agimem.com>
Subject Re: Moving some minor issues from 0.0.2 to 0.0.1 to get them committed before the release?
Date Mon, 07 Mar 2011 10:23:42 GMT
I Agree. Which issues do you thing are the priority.

In my opinion, the aim of releasing 0.0.1 was mainly to set a cycle for the
development not to block it. We reached this goal by resolving the opened
issues. If the effort required to release droids in maven repositories is
too important, I even propose to create the tag for 0.0.1 without releasing
and starting the development of 0.0.2.


On 5 March 2011 22:38, Eugen Paraschiv <hanriseldon@gmail.com> wrote:

> I have worked on a production project involving heavy branching in the
> past,
> and I can tell you the effort, especially dealing with SVN is significant -
> it does introduce a lot of complexity. So, to come back to my original
> questions - first, is there any news on the release process? Is there a
> need
> for work in a specific area?
> And second, assuming the release not going to be done in the next few days,
> and that the idea of the stable branch is most likely on hold, would a good
> solution be to move the issues with patches back to 0.0.1 in order to get
> them accepted and committed quickly? The purpose of this is to not be
> blocked by the release process, and also to get as much work as possible
> into 0.0.1. Most of the issues are not logically tied to 0.0.2 in any way,
> so they can easily be committed in 0.0.1.
>
>
> On Thu, Mar 3, 2011 at 9:53 AM, Chapuis Bertil <bchapuis@agimem.com>
> wrote:
>
> > You are probably right. I see the stable branch more as a snapshot of the
> > trunk, and the merges should mainly be done from trunk to stable, however
> I
> > don't know how time consuming it is to perform these merges. The point is
> > that the release should not be blocking. Do you think we can find another
> > alternative?
> >
> > On 3 March 2011 00:33, Richard Frovarp <rfrovarp@apache.org> wrote:
> >
> > > On 03/02/2011 04:03 PM, Chapuis Bertil 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/
> > >>
> > >>
> > >>
> > > The Incubator docs link to that blog entry as well. I don't know that I
> > see
> > > the benefit of going to this.
> > >
> > > The entry states this:
> > >
> > > "Usually when explaining this model to a new group of developers they
> > > realize at some point someone (like Bob) or some people will have to do
> > the
> > > work of merging changes from trunk to stable, and that the tool support
> > for
> > > stuff like that is a bit limited."
> > >
> > > and this
> > >
> > > "For small and/or mature projects I do often revert back to having just
> a
> > > trunk."
> > >
> > >
> > > So who is going to do that work on this project? My concern is that
> > merges
> > > will always happen, which is just an extra step to do beyond using just
> a
> > > trunk. The other option is that merges rarely happen, and trying to
> > figure
> > > out what needs to be merged becomes a problem.
> > >
> >
> >
> >
> > --
> > Bertil Chapuis
> > Agimem Sàrl
> > http://www.agimem.com
> >
>



-- 
Bertil Chapuis
Agimem Sàrl
http://www.agimem.com

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