[aerogear-dev] Versioning

[Sebastien Blanc]

make sense, go go go for suffixes !



On Thu, Jun 6, 2013 at 2:42 PM, Kris Borchers <kris at redhat.com> wrote:

>
> On Jun 6, 2013, at 7:39 AM, Sebastien Blanc <scm.blanc at 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 at redhat.com> wrote:
>
>>
>> On Jun 6, 2013, at 6:36 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>
>>
>> On Jun 5, 2013, at 3:56 PM, Kris Borchers <kris at 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:
>>
>>
>>    1. I would like to move what is currently in master to a 1-0-stable
>>    branch
>>    2. Then I would like to update master's build version to 1.1.0-pre
>>    3. 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
>>
>>
>>
>>    1. make your change on master, commit and push
>>    2. git log
>>    3. copy the SHA from your commit
>>    4. git checkout 1.0-stable
>>    5. git cherry-pick <SHA from log>
>>    6. push to 1.0-stable
>>    7. profit
>>
>>
>>
>> Then, going forward:
>>
>>
>>    1. Any patch releases for 1.0.x would come from the 1-0-stable branch
>>    2. 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
>>    3. 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 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
>
>
>
> _______________________________________________
> 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/20130606/2587598d/attachment.html