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 yo
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
> 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
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 m
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 whe
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-dimensio
Jordan K. Hubbard wrote:
> That's either truly one-dimensional thinking at work or you are now
> merely working overtime try and invent reasons to branch. :-)
No, I still try to understand how your proposal should be useful.
> Who says that the only way to fix bugs is to branch? You might just
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 an
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
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 re
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
>>
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
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
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 branc
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
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
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 u
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 t
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
> 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:
> 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
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
> 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 two
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 two-b
Randall Wood wrote:
> SO when are we planning on getting a macports (1.6.1, 1.7.0) out that
> addresses this issue?
There were a lot of changes to trunk. But not all of them are suited for
inclusion in a 1.6.1 release.
To make a 1.6.1 release a lot of revisions still need to get merged to
the r
26 matches
Mail list logo
