[aerogear-dev] Maintenance branches

[Sebastien Blanc]

+1 I like this approach

*naming *policy versioning and *branching *policy are IMO 2 differents
things

On Fri, Mar 22, 2013 at 1:32 PM, Kris Borchers <kris at redhat.com> wrote:

> I definitely think branches are necessary. Just from my experience with
> jQuery, this has worked well.
>
> When a new stable, minor version is released, a branch is created for it.
> So we would create a 1.0-stable branch or something like that. When bugs
> are fixed, they are fixed in master, then cherry-picked over to the current
> stable branch. When we are ready for a patch release (1.0.1 for example),
> that can be tagged directly from the 1.0-stable branch and all of those bug
> fixes already exist in master.
>
> In the meantime, new features (Notifier for example) are developed in a
> feature branch (currently we are doing that in the Notifier branch). Those
> branches occasionally have master merged into them to keep them up to date.
> Then, when we are ready to add a feature to the next release, the feature
> branch is merged into master. Then, based on our versioning policy, we
> create a new minor or major release by first creating a new stable branch
> (1.1-stable or 2.0-stable depending on what we're releasing), tag the
> release from that new branch, then delete the old stable branch.
>
> I really like this method because it allows for simultaneous new
> development and maintenance and easily keeps all branches and releases up
> to date with latest bug fixes.
>
> Thoughts?
>
> On Mar 22, 2013, at 7:22 AM, Daniel Passos <daniel at passos.me> wrote:
>
> IMO tags work fine.
>
> I don't think a branch is necessary. If we have something to fix, we
> create a temporary branch, fix, merge to master and create a tag for it
>
> Daniel Passos
>
> On Fri, Mar 22, 2013 at 7:03 AM, Bruno Oliveira <bruno at abstractj.org>wrote:
>
>> Hi Dan, I believe that we will stick with the following approach
>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-RFC-Initial-Versioning-Policy-td1914.html
>>
>>
>>
>> --
>> "The measure of a man is what he does with power" - Plato
>> -
>> @abstractj
>> -
>> Volenti Nihil Difficile
>>
>>
>>
>> On Friday, March 22, 2013 at 6:57 AM, Daniel Bevenius wrote:
>>
>> > > I'm not sure if we really need branches, maybe just tags?
>> >
>> > Not sure how that would work but I'd be interested to learn. I could
>> not determine just by looking at the torguebox repo as then have branches
>> for what looks like maintenance/dev releases (and also tags of course)
>> > As long as we all do the same I'm happy.
>> >
>> >
>> >
>> > On 22 March 2013 10:23, Bruno Oliveira <bruno at abstractj.org (mailto:
>> bruno at abstractj.org)> wrote:
>> > > I'm not sure if we really need branches, maybe just tags?
>> https://github.com/torquebox/torquebox for example has been working with
>> tags, branches at least to me might lead to confusion.
>> > >
>> > >
>> > > --
>> > > "The measure of a man is what he does with power" - Plato
>> > > -
>> > > @abstractj
>> > > -
>> > > Volenti Nihil Difficile
>> > >
>> > >
>> > >
>> > > On Friday, March 22, 2013 at 6:18 AM, Sebastien Blanc wrote:
>> > >
>> > > > +1 to create a 1.0.0 branch
>> > > > For 1.0.1 not sure if it has to be also branch or just the master
>> otherwise Master should be for 1.1 stuff ?
>> > > > Seb
>> > > >
>> > > >
>> > > >
>> > > > On Fri, Mar 22, 2013 at 10:12 AM, Daniel Bevenius <
>> daniel.bevenius at gmail.com (mailto:daniel.bevenius at gmail.com) (mailto:
>> daniel.bevenius at gmail.com)> wrote:
>> > > > > Hi all,
>> > > > >
>> > > > > I'd like to discuss how to handle maintenance branches. Sorry if
>> this has already been discussed, I think Kris posted something about this
>> but I was not able to find it.
>> > > > >
>> > > > > For example, now that we are about to release 1.0.0 we will tag
>> that release. After that should we create a 1.0.1 branch for
>> patches/bugfixes and then continue with new features in master?
>> > > > >
>> > > > > Since we are in a waiting state at the moment, which could happen
>> again, should we perhaps create a branch named 1.0.0, which we can use
>> until the release and then tag it and remove that branch. After that any
>> issues would be fixed in the 1.0.1 branch.
>> > > > >
>> > > > > Does this sound correct?
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > /Dan
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > aerogear-dev mailing list
>> > > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>> (mailto:aerogear-dev at lists.jboss.org)
>> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > aerogear-dev mailing list
>> > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>> (mailto:aerogear-dev at lists.jboss.org)
>> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130322/78c8f2ab/attachment.html