7:42 a.m.
On Jun 6, 2013, at 7:39 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
+1 on the flow , just not sure for the naming if we need the suffixes
"stable" and "pre"
I like the pre suffix because it is added to the built files. Otherwise, the built file
would be versioned as 1.1.0 for example which would be misleading since it hasn't been
released yet.
As for the stable suffix, I can go either way on that. I like it to let people know that
branch is our stable branch but if others don't like it, I am fine with not doing
that.
On Thu, Jun 6, 2013 at 2:32 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jun 6, 2013, at 6:36 AM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
>
> On Jun 5, 2013, at 3:56 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
>> So we haven't talked about this for a while so I thought I would stir the
fire again. Does anyone have any objection to JS managing our versions as such:
>>
>> I would like to move what is currently in master to a 1-0-stable branch
>> Then I would like to update master's build version to 1.1.0-pre
>> All work is done on the master branch then if the change is applicable to 1.0.0,
it can be cherry-picked into the 1-0-stable branch
>
> i need a crash course on cherry picking
make your change on master, commit and push
git log
copy the SHA from your commit
git checkout 1.0-stable
git cherry-pick <SHA from log>
push to 1.0-stable
profit
>
>>
>> Then, going forward:
>>
>> Any patch releases for 1.0.x would come from the 1-0-stable branch
>> When 1.1.0 is released, the new version would be tagged from master, then
branched into a 1-1-stable branch, then the 1-0-stable branch would be deleted
>> Master would then be updated to 1.2.0-pre
>>
>> The biggest reason for this is it allows continued work on new features to be
merged into their release version from their development branch when ready, rather than
waiting until right before a release to put it all together. If we don't do that, and
merge something like Notifier into master when it's "ready", we can no
longer release maintenance versions for the current stable release because those new
features would be included.
>>
>> Thoughts?
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev