bumping version to 0.1.0

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bumping version to 0.1.0

Joe Witt
Hello

With 0.0.2 behind us now we can start preperations for the next
planned release which is 0.1.0.  In it we can include the stuff Dan
Bress had planned and we can start folding in some of these things
which have been on branches.

My git/git-flow foo isn't up to par to understand the right way that
we'd do an 0.0.3 if we had to.  But seems easy enough given the tag
and the fact that master is the view right after the release.

Thanks
Joe
Reply | Threaded
Open this post in threaded view
|

Re: bumping version to 0.1.0

Brandon DeVries
In this case to create a 0.0.3 we would probably want to create a branch
from the 0.0.2 tag (possibly called something like "release-0.0").  When
the 0.1.0 release is "ready" (and I'll try to get the documentation updated
before that), the proposed model would be to create a "release-0.1" branch,
test until comfortable, and then release 0.1.0 from that branch.  Then if
0.1.1 should become necessary, we continue working from the "release-0.1"
branch, cherry picking from master as needed.

Brandon

On Tue, Mar 17, 2015 at 9:30 AM Joe Witt <[hidden email]> wrote:

> Hello
>
> With 0.0.2 behind us now we can start preperations for the next
> planned release which is 0.1.0.  In it we can include the stuff Dan
> Bress had planned and we can start folding in some of these things
> which have been on branches.
>
> My git/git-flow foo isn't up to par to understand the right way that
> we'd do an 0.0.3 if we had to.  But seems easy enough given the tag
> and the fact that master is the view right after the release.
>
> Thanks
> Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: bumping version to 0.1.0

Dan Bress
I agree with what Brandon said.  I think someone should run mvn versions:set "0.1.0-SNAPSHOT" on develop, to make it clear what we are working towards there.

Brandon,  when you are writing your release/branch guide, consider mentioning the mvn release:branch plugin.  I've used it in the past, and found it helpful.  In short it will make a branch, and then run mvn versions:set on the parent to set it to whatever the next version is.  We would only want to use this to make the "release branches" that Brandon is talking about, not feature branches.

Dan Bress
Software Engineer
ONYX Consulting Services

________________________________________
From: Brandon DeVries <[hidden email]>
Sent: Tuesday, March 17, 2015 10:02 AM
To: [hidden email]
Subject: Re: bumping version to 0.1.0

In this case to create a 0.0.3 we would probably want to create a branch
from the 0.0.2 tag (possibly called something like "release-0.0").  When
the 0.1.0 release is "ready" (and I'll try to get the documentation updated
before that), the proposed model would be to create a "release-0.1" branch,
test until comfortable, and then release 0.1.0 from that branch.  Then if
0.1.1 should become necessary, we continue working from the "release-0.1"
branch, cherry picking from master as needed.

Brandon

On Tue, Mar 17, 2015 at 9:30 AM Joe Witt <[hidden email]> wrote:

> Hello
>
> With 0.0.2 behind us now we can start preperations for the next
> planned release which is 0.1.0.  In it we can include the stuff Dan
> Bress had planned and we can start folding in some of these things
> which have been on branches.
>
> My git/git-flow foo isn't up to par to understand the right way that
> we'd do an 0.0.3 if we had to.  But seems easy enough given the tag
> and the fact that master is the view right after the release.
>
> Thanks
> Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: bumping version to 0.1.0

Joe Witt
0.1.0-incubating-SNAPSHOT about to be pushed.  Am testing it now

On Tue, Mar 17, 2015 at 10:09 AM, Dan Bress <[hidden email]> wrote:

> I agree with what Brandon said.  I think someone should run mvn versions:set "0.1.0-SNAPSHOT" on develop, to make it clear what we are working towards there.
>
> Brandon,  when you are writing your release/branch guide, consider mentioning the mvn release:branch plugin.  I've used it in the past, and found it helpful.  In short it will make a branch, and then run mvn versions:set on the parent to set it to whatever the next version is.  We would only want to use this to make the "release branches" that Brandon is talking about, not feature branches.
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>
> ________________________________________
> From: Brandon DeVries <[hidden email]>
> Sent: Tuesday, March 17, 2015 10:02 AM
> To: [hidden email]
> Subject: Re: bumping version to 0.1.0
>
> In this case to create a 0.0.3 we would probably want to create a branch
> from the 0.0.2 tag (possibly called something like "release-0.0").  When
> the 0.1.0 release is "ready" (and I'll try to get the documentation updated
> before that), the proposed model would be to create a "release-0.1" branch,
> test until comfortable, and then release 0.1.0 from that branch.  Then if
> 0.1.1 should become necessary, we continue working from the "release-0.1"
> branch, cherry picking from master as needed.
>
> Brandon
>
> On Tue, Mar 17, 2015 at 9:30 AM Joe Witt <[hidden email]> wrote:
>
>> Hello
>>
>> With 0.0.2 behind us now we can start preperations for the next
>> planned release which is 0.1.0.  In it we can include the stuff Dan
>> Bress had planned and we can start folding in some of these things
>> which have been on branches.
>>
>> My git/git-flow foo isn't up to par to understand the right way that
>> we'd do an 0.0.3 if we had to.  But seems easy enough given the tag
>> and the fact that master is the view right after the release.
>>
>> Thanks
>> Joe
>>