You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Hugo Trippaers <HT...@schubergphilis.com> on 2012/10/01 19:34:42 UTC
Switching master to version 4.1.0
Heya all,
With the 4.0.0 branch ready for the final stages toward the release I think it's time to up the version number of the master branch. If there are no objections I will go ahead and change the version number of master to 4.1.0.
I think for the future this should happen directly after we make a branch for a release so it is very clear what versions people are working on and prevents mismatches from happening when people are working on both the branch and the master at the same time. We don't want somebody pulling in a dependency from that master branch into the release compile just because it compiled more recently ;-)
Cheers,
Hugo
RE: Switching master to version 4.1.0
Posted by Alex Huang <Al...@citrix.com>.
I've also added this page [1] to keep track of features that will be in 4.1.0. Please use that to submit your features and specs, etc.
--Alex
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Next+Release
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, October 01, 2012 11:13 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Switching master to version 4.1.0
>
> On Mon, Oct 1, 2012 at 2:00 PM, Hugo Trippaers
> <HT...@schubergphilis.com> wrote:
> > Hey Chip,
> >
> > Just the same way, after we make the last release brach in the 4.x.x branch
> we up the version number to 5.x.x. If we decide to up to 5 somewhere later
> it is not a problem to up the version of the master brach to 5 while
> developing. And it's just a single command so pretty painless.
>
> Good point. Then I'm +1 for this.
>
> > Cheers,
> >
> > Hugo
> >
> > Verstuurd vanaf mijn iPad
> >
> > Op 1 okt. 2012 om 10:50 heeft "Chip Childers" <ch...@sungard.com>
> het volgende geschreven:
> >
> >> On Mon, Oct 1, 2012 at 1:34 PM, Hugo Trippaers
> >> <HT...@schubergphilis.com> wrote:
> >>> Heya all,
> >>>
> >>> With the 4.0.0 branch ready for the final stages toward the release I
> think it's time to up the version number of the master branch. If there are no
> objections I will go ahead and change the version number of master to 4.1.0.
> >>
> >> +1
> >>
> >>> I think for the future this should happen directly after we make a
> >>> branch for a release so it is very clear what versions people are
> >>> working on and prevents mismatches from happening when people are
> >>> working on both the branch and the master at the same time. We don't
> >>> want somebody pulling in a dependency from that master branch into
> >>> the release compile just because it compiled more recently ;-)
> >>
> >> A slight concern here would be when it comes time to decide to up the
> >> major version number to 5. Any thoughts on how to handle that?
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >
Re: Switching master to version 4.1.0
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Oct 1, 2012 at 2:00 PM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> Hey Chip,
>
> Just the same way, after we make the last release brach in the 4.x.x branch we up the version number to 5.x.x. If we decide to up to 5 somewhere later it is not a problem to up the version of the master brach to 5 while developing. And it's just a single command so pretty painless.
Good point. Then I'm +1 for this.
> Cheers,
>
> Hugo
>
> Verstuurd vanaf mijn iPad
>
> Op 1 okt. 2012 om 10:50 heeft "Chip Childers" <ch...@sungard.com> het volgende geschreven:
>
>> On Mon, Oct 1, 2012 at 1:34 PM, Hugo Trippaers
>> <HT...@schubergphilis.com> wrote:
>>> Heya all,
>>>
>>> With the 4.0.0 branch ready for the final stages toward the release I think it's time to up the version number of the master branch. If there are no objections I will go ahead and change the version number of master to 4.1.0.
>>
>> +1
>>
>>> I think for the future this should happen directly after we make a branch for a release so it is very clear what versions people are working on and prevents mismatches from happening when people are working on both the branch and the master at the same time. We don't want somebody pulling in a dependency from that master branch into the release compile just because it compiled more recently ;-)
>>
>> A slight concern here would be when it comes time to decide to up the
>> major version number to 5. Any thoughts on how to handle that?
>>
>>>
>>> Cheers,
>>>
>>> Hugo
>
Re: Switching master to version 4.1.0
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey Chip,
Just the same way, after we make the last release brach in the 4.x.x branch we up the version number to 5.x.x. If we decide to up to 5 somewhere later it is not a problem to up the version of the master brach to 5 while developing. And it's just a single command so pretty painless.
Cheers,
Hugo
Verstuurd vanaf mijn iPad
Op 1 okt. 2012 om 10:50 heeft "Chip Childers" <ch...@sungard.com> het volgende geschreven:
> On Mon, Oct 1, 2012 at 1:34 PM, Hugo Trippaers
> <HT...@schubergphilis.com> wrote:
>> Heya all,
>>
>> With the 4.0.0 branch ready for the final stages toward the release I think it's time to up the version number of the master branch. If there are no objections I will go ahead and change the version number of master to 4.1.0.
>
> +1
>
>> I think for the future this should happen directly after we make a branch for a release so it is very clear what versions people are working on and prevents mismatches from happening when people are working on both the branch and the master at the same time. We don't want somebody pulling in a dependency from that master branch into the release compile just because it compiled more recently ;-)
>
> A slight concern here would be when it comes time to decide to up the
> major version number to 5. Any thoughts on how to handle that?
>
>>
>> Cheers,
>>
>> Hugo
Re: Switching master to version 4.1.0
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Oct 1, 2012 at 1:34 PM, Hugo Trippaers
<HT...@schubergphilis.com> wrote:
> Heya all,
>
> With the 4.0.0 branch ready for the final stages toward the release I think it's time to up the version number of the master branch. If there are no objections I will go ahead and change the version number of master to 4.1.0.
+1
> I think for the future this should happen directly after we make a branch for a release so it is very clear what versions people are working on and prevents mismatches from happening when people are working on both the branch and the master at the same time. We don't want somebody pulling in a dependency from that master branch into the release compile just because it compiled more recently ;-)
A slight concern here would be when it comes time to decide to up the
major version number to 5. Any thoughts on how to handle that?
>
> Cheers,
>
> Hugo
Re: Switching master to version 4.1.0
Posted by Noah Slater <ns...@tumbolia.org>.
Few comments.
It would be good to get your roadmap, Git branching/merging, and version
number policy documented.
At Apache CouchDB, we're attempting to do something along those lines with
these:
http://wiki.apache.org/couchdb/Roadmap_Process
http://wiki.apache.org/couchdb/Merge_Procedure
(Summary: work happens on master, new release branches are created
immediately after each release, features are merged in once they're ready,
along with tests, docs, etc, etc. Simplifies the eventual process of
cutting a release.)
We're still working it out though, so it's just a data point.
As for when to bump to 5.0. Do that whenever you introduce breaking
changes. Preferably along with the commit. (That is, major revisions, IMO
should be tied to breaking changes, not marketing efforts.)
cf. http://semver.org/
On Mon, Oct 1, 2012 at 6:34 PM, Hugo Trippaers <
HTrippaers@schubergphilis.com> wrote:
> Heya all,
>
> With the 4.0.0 branch ready for the final stages toward the release I
> think it's time to up the version number of the master branch. If there are
> no objections I will go ahead and change the version number of master to
> 4.1.0.
>
> I think for the future this should happen directly after we make a branch
> for a release so it is very clear what versions people are working on and
> prevents mismatches from happening when people are working on both the
> branch and the master at the same time. We don't want somebody pulling in a
> dependency from that master branch into the release compile just because it
> compiled more recently ;-)
>
> Cheers,
>
> Hugo
>
--
NS