On Tue, Mar 22, 2016 at 5:10 AM, Kevin Klues wrote:
> This way it's easy to track the full set of release candidates, as well as
> how they relate to previous release candidates, minor releases, and point
> releases.
There is no essential difference with the current approach
On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues wrote:
> I respectfully disagree.
>
> The whole purpose of tags is to mark permanent things like releases,
> whereas branches are designed as temporary lines of development that
> come and go (and grow and shrink) dynamically all the
The way I've dealt with this on other projects in the past is the following:
1) RC1s for minor releases (e.g., 0.28.0-rc1, 0.29.0-rc1, 0.30-rc1, etc.)
are *always* tagged at some commit on the master branch.
This is only true for actual minor release (i.e. not point releases, e.g.
0.28.1,
+1 for branch per RC (if we go with branches). I like your argument against
re-writing history if we make a mistake.
I think the 2 issues that have come up are:
1) visibility into the release process
2) pain / lack of context for the release manager of backports to resolve
merge conflicts for
A single branch for a release seems brittle because it assumes that RC tag
N shares the same lineage as RC tag N-1. This is mostly true, but not
always. The branching approach that would mirror how I've put together
releases would be to have a branch for each RC. The RC N branch is usually
on top
The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes into
release candidates.
I'm all for using branches in the repository to put together the release
candidates, as well as have committers consider their bug fixes for some N
number of backport (future LTS) releases.
As Kevin
On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu wrote:
> Cong Wang,
>
> The tags are sync'd. See: https://github.com/apache/mesos/releases
>
> You might not have done: git pull --tags
Yeah, I figured it out by myself too. This is why I hate tags personally,
branches are
On Wed, Mar 16, 2016 at 11:49 AM, Cong Wang wrote:
> On Mon, Mar 7, 2016 at 8:29 PM, Michael Park wrote:
>> Please find the release at:
>> https://dist.apache.org/repos/dist/release/mesos/0.27.2
>>
>> It is recommended to use a mirror to download the
I like the idea of using branches to manage releases.
We can use that to manage point releases and backports as well.
Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in that
branch. Once the RC is accepted, the head of that branch will become the
release.
Then, we immediate
Cong Wang,
The tags are sync'd. See: https://github.com/apache/mesos/releases
You might not have done: git pull --tags
On Wed, Mar 16, 2016 at 11:49 AM, Cong Wang wrote:
> On Mon, Mar 7, 2016 at 8:29 PM, Michael Park wrote:
> > Please find the
On Mon, Mar 7, 2016 at 8:29 PM, Michael Park wrote:
> Please find the release at:
> https://dist.apache.org/repos/dist/release/mesos/0.27.2
>
> It is recommended to use a mirror to download the release:
> http://www.apache.org/dyn/closer.cgi
>
> The CHANGELOG for the release is
I agree with Kevin -- tags are immutable, so they're naturally suited
for labeling releases, which ought to be immutable too.
On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues wrote:
> I respectfully disagree.
>
> The whole purpose of tags is to mark permanent things like releases,
I respectfully disagree.
The whole purpose of tags is to mark permanent things like releases,
whereas branches are designed as temporary lines of development that
come and go (and grow and shrink) dynamically all the time.
On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu wrote:
> I
BTW, if the tag is created against a commit that *doesn't* become
"unreachable" from HEAD [1], then `git pull` is sufficient to also pull
down the tags.
The only time I've needed to do `git fetch --tags` is when the tagged
commit SHA gets merged away. So presumably the process being followed by
@team, are we going to provide LTS version? If so, we definitely need a
branch to back merge issues; if not, we release a new version monthly (??),
we'd suggest user to upgrade to next release.
Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
Platform OpenSource Technology, STG, IBM
The Mesosphere deb/rpm packages are available here:
http://open.mesosphere.com/downloads/mesos/
On 7 March 2016 at 23:29, Michael Park wrote:
> Hi all,
>
> The vote for Mesos 0.27.2 (rc1) has passed with the
> following votes.
>
> +1 (Binding)
> --
16 matches
Mail list logo