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 Mon, 07 Mar 2011 16:09:24 GMT
Ok, thanks for the answer, I'll list them later on today.
The problem with the tag is the fact that it interferes with the way
maven-release-plugin works - it needs to work from the trunk and it takes
care of creating the tag in svn, so if we would try to release from the tag,
I'm unsure how it would behave but I'm certain it would increase the
complexity of the release process. That is the reason I suggested simply
moving some of the done issues back to 0.0.1, because it wouldn't affect the
release at all.
Ok, so I will provide a list of issues today as the ones I see as ready to
be reviewed. Once they are accepted, I'll move them to 0.0.1 so that they
can be comitted and closed off.
Thanks.
Eugen.

On Mon, Mar 7, 2011 at 12:23 PM, Chapuis Bertil <bchapuis@agimem.com> wrote:

> 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