The latest release process document is now in svn at
site/trunk/content/developing/releasing.md
It hasn't yet propagated to the HTML view, when it does it will be at
http://slider.incubator.apache.org/developing/releasing.html
I think we've outgrown the git flow release process.
The feature bra
I vote for removing the master branch. This is in the line of what I was
also wondering since we have created branches for 0.60 and 0.70. Branches
can remain the source of truth for the release and can facilitate minor
releases if needed.
On Wed, Jan 28, 2015 at 8:58 AM, Steve Loughran
wrote:
>
Could also just remove "master" in its current use and
s/develop/master/, leveraging the master branch as the normal place
things are implemented.
It really doesn't matter in the end (it's just a name), but, if this is
also signifying a move away from git-flow, it makes more sense to me to
us
The most common use I have seen for the master branch, is to signify that
it contains the most recent release of the product. The individual release
branches would still be there, like releases/slider-0.60,
releases/slider-0.70, etc. But for anyone who would just need the latest
release would not h
Agree that master will serve a purpose. develop may go through bouts of
"being temporarily in bad state" due to live coding.
The question is will a user, wanting to use the latest, prefer
1) the master branch that can get updated upon release (can be a surprise
if you do a git pull)
2) the latest
Totally agree. Pretty much comes down to what do we think a user will
want by default like you said.
Will they want a specific tag from a release, the branch for some
long-lived version, or the "latest"?
I think both have merit (I can't really say I see a "stable" master more
frequently than
If we are in an impasse, then lesser branches to manage is better :-)
-Sumit
From: Josh Elser
Sent: Wednesday, January 28, 2015 3:12 PM
To: dev@slider.incubator.apache.org
Subject: Re: updating the release process; what to do about branches
Totally agree
org
Subject: Re: updating the release process; what to do about branches
Could also just remove "master" in its current use and
s/develop/master/, leveraging the master branch as the normal place
things are implemented.
It really doesn't matter in the end (it's just a name), but, if
Sumit
From: Josh Elser
Sent: Wednesday, January 28, 2015 3:12 PM
To: dev@slider.incubator.apache.org
Subject: Re: updating the release process; what to do about branches
Totally agree. Pretty much comes down to what do we think a user will
want by default lik
[gitflow "branch"]
> master = master
> develop = develop
>
>
> From: Josh Elser
> Sent: 28 January 2015 18:02
> To: dev@slider.incubator.apache.org
> Subject: Re: updating the release process; what to do about branches
>
> Could also
ster = master
> develop = develop
>
> ____
> From: Josh Elser
> Sent: 28 January 2015 18:02
> To: dev@slider.incubator.apache.org
> Subject: Re: updating the release process; what to do about branches
>
> Could also just remove "mast
+1.
From: Steve Loughran
Sent: Monday, February 02, 2015 4:26 AM
To: dev@slider.incubator.apache.org
Subject: Re: updating the release process; what to do about branches
Following up now that I am in track of emails again.
Assuming we stay with develop
12 matches
Mail list logo
