I think the amount of work to use a branch is overestimated. It's not hard
and
very easy and safer then having everything in trunk and then having to do code
freezes.
I think the amount of time passed since the 1.6.0 release and the
amount of time since
1.6.1 is vaporware, combined with
On May 29, 2008, at 03:11, Caspar Florian Ebeling wrote:
I think the amount of work to use a branch is overestimated. It's
not hard and
very easy and safer then having everything in trunk and then
having to do code
freezes.
I think the amount of time passed since the 1.6.0 release
On May 28, 2008, at 5:27 AM, Rainer Müller wrote:
If you don't branch, you need a code freeze to avoid other changes
happen on trunk which you don't want to have in your release. So,
again you need a release engineer to announce code freezes.
Code freezes make your development slower as
Jordan K. Hubbard wrote:
On May 27, 2008, at 6:28 PM, Rainer Müller wrote:
Hm, this sounds like you propose here to make release branches
without using tags.
No. From the very beginning of my proposal (please go back and read
my first message again) I have suggested making releases
Joshua Root wrote:
I would have no objection to tagging trunk today and calling it an -rc1.
Well, except that there are apparently some bug fixes in the 1.6 branch
that are not in trunk - argh!
But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where do
you fix a bug found in
On May 27, 2008, at 11:52 PM, Rainer Müller wrote:
But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where
do you fix a bug found in that rc1? On and trunk and you merge it
back to the 1.7.x release branch
That's either truly one-dimensional thinking at work or you are now
As I stated earlier, if you did not make point releases from a given
release then it wouldn't be a branch- it would be immutable and
therefore te default MO would be to make it a tag. I'm all for using
the correct semantics, but the semantics here are variable based on
subsequent events
Jordan K. Hubbard wrote:
On May 27, 2008, at 11:52 PM, Rainer Müller wrote:
But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where
do you fix a bug found in that rc1? On and trunk and you merge it
back to the 1.7.x release branch
That's either truly one-dimensional
Rainer Müller wrote:
Joshua Root wrote:
I would have no objection to tagging trunk today and calling it an -rc1.
Well, except that there are apparently some bug fixes in the 1.6 branch
that are not in trunk - argh!
But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where do
Blair Zajac wrote:
Rainer Müller wrote:
So if a release was near, I would do (with some pseudo-shell commands):
svn cp trunk branches/release_1_7
svn cp branches/release_1_7 tags/release_1_7_0-rc1
Bug fixes go to branches/release_1_7. Anything can happen on trunk in
the mean time. If
This is why I think that releases should be tags on trunk, with a
convergence period before each release. This project is not big
enough and does not have the manpower or written guidelines and a
release engineer driving the process on a daily basis which are
necessary to really do a
This is why I think that releases should be tags on trunk, with a
convergence period before each release. This project is not big
enough and does not have the manpower or written guidelines and a
release engineer driving the process on a daily basis which are
necessary to really do a
Jordan K. Hubbard wrote:
This is why I think that releases should be tags on trunk, with a
convergence period before each release. This project is not big
enough and does not have the manpower or written guidelines and a
release engineer driving the process on a daily basis which are
Caspar Florian Ebeling wrote:
This is exactly what I have been preaching, but I think it changes
with Git. I know that saying this might well be boring by now, but Git
eases the whole branch handling a lot. And svnmerge.py is really
not a substitute here. I used it for a feature branch of a
Git is just another version control system and does not decide if we make
feature branches or not. Yes, merging in Subversion is not the best, but
this will become a lot better with Subversion 1.5. I don't think we have to
discuss different version control systems and their advantages here.
Caspar Florian Ebeling wrote:
Git is just another version control system and does not decide if we make
feature branches or not. Yes, merging in Subversion is not the best, but
this will become a lot better with Subversion 1.5. I don't think we have to
discuss different version control systems
Caspar Florian Ebeling wrote:
Yeah, and that's the whole problem. With svn you dump all your new
half-cooked,
half-done features into trunk. With Git it's the reverse situation.
You do the dangerous
things in branches and can assume that mainline is reasonably in shape. That's
only a
On May 27, 2008, at 12:38 PM, Caspar Florian Ebeling wrote:
This is exactly what I have been preaching, but I think it changes
with Git. I know that saying this might well be boring by now, but Git
eases the whole branch handling a lot. And svnmerge.py is really
not a substitute here. I used
On May 27, 2008, at 12:48 PM, Rainer Müller wrote:
If we would do this the way you describe, every new feature would
have to be developed on a different branch.
I think this depends entirely on what you call a feature. If by
feature you mean something which is going to take a long time
On May 27, 2008, at 1:38 PM, Rainer Müller wrote:
Jordan brings up the idea not to use branches at all, but to make
releases from the main line. [ ... ] How would we do minor releases
for bugfixes without branches?
Easy. In Subversion, tags and branches are the same thing - it's just
Jordan K. Hubbard wrote:
On May 27, 2008, at 1:38 PM, Rainer Müller wrote:
Jordan brings up the idea not to use branches at all, but to make
releases from the main line. [ ... ] How would we do minor releases
for bugfixes without branches?
Easy. In Subversion, tags and branches are
On May 27, 2008, at 6:28 PM, Rainer Müller wrote:
Hm, this sounds like you propose here to make release branches
without using tags.
No. From the very beginning of my proposal (please go back and read
my first message again) I have suggested making releases WITH tags.
WITH.
- Jordan
On May 27, 2008, at 6:28 PM, Rainer Müller wrote:
What I didn't like about your initial proposal was the convergence
period which I interpreted to put trunk into code freeze. In my
opinion, you should branch off the release if you think the current
feature set in trunk would make a
Jordan K. Hubbard wrote:
On May 27, 2008, at 6:28 PM, Rainer M?ller wrote:
What I didn't like about your initial proposal was the convergence
period which I interpreted to put trunk into code freeze. In my
opinion, you should branch off the release if you think the current
feature set
24 matches
Mail list logo
