Hi all,
while the new convention is agreed-upon and fixed, I'm refreshing
this discussion to point to a quite insightful article by Linus
Torvalds on the releases issue:
http://torvalds-family.blogspot.com/2008/10/on-making-releases.html
Ciao!
--
/kinkie
On fre, 2008-09-26 at 13:25 +1200, Amos Jeffries wrote:
> logdaemon, internal redirectors, and netdb are big component changes. But
> not squid-wide.
Yes. Isolated feature changes. Number of lines added/deleted does not
matter much, the complexity is in the amount of changes to existing
code.
> T
> On Thu, 2008-09-25 at 22:40 +0200, Henrik Nordstrom wrote:
>
>> My vote:
>>
>> 1. Finish any pending major restucturing/reorganisations/reformmatting
>> first. For example if the code is to be restyled before 3.1 is "old and
>> mature" then it must be done before 3.1 is branched. Such changes is
> On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote:
>
>> Understood. What do you think is better:
>>
>> A) Branch and commit waiting stuff to trunk now. Deal with a large
>> volume of complicated commit traffic between the 3.1 branch and trunk.
>>
>> B) Branch and commit waiting stuff later.
On Thu, 2008-09-25 at 22:40 +0200, Henrik Nordstrom wrote:
> My vote:
>
> 1. Finish any pending major restucturing/reorganisations/reformmatting
> first. For example if the code is to be restyled before 3.1 is "old and
> mature" then it must be done before 3.1 is branched. Such changes is a
> maj
On Thu, 2008-09-25 at 22:53 +0200, Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote:
>
> > If we use RC label for selected/last 4-digit releases, then we will not
> > have the above problems. If a 4-digit release proves stable, we post
> > 3.1.1 (an exact copy of th
On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote:
> If we use RC label for selected/last 4-digit releases, then we will not
> have the above problems. If a 4-digit release proves stable, we post
> 3.1.1 (an exact copy of the last successful 4-digit release, except for
> the version number) a
On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote:
> Understood. What do you think is better:
>
> A) Branch and commit waiting stuff to trunk now. Deal with a large
> volume of complicated commit traffic between the 3.1 branch and trunk.
>
> B) Branch and commit waiting stuff later. Focus o
On Thu, 2008-09-25 at 13:50 -0600, Alex Rousskov wrote:
> On Thu, 2008-09-25 at 21:34 +0200, Henrik Nordstrom wrote:
>
> > Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not
> > yet on the FTP server or announced on squid-announce, and labelled as an
> > release candidate on t
On Thu, 2008-09-25 at 21:34 +0200, Henrik Nordstrom wrote:
> Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not
> yet on the FTP server or announced on squid-announce, and labelled as an
> release candidate on the web server.
>
> Before that there is also the nightly snapshot
On tor, 2008-09-25 at 08:40 -0600, Alex Rousskov wrote:
> I do not want the meaningful words like "RC" or "STABLE" to be in the
> version string. And I want a way to release many times with a specific
> version (not an automated snapshot) before the branch is marked as
> stable.
Same here, but I
On tor, 2008-09-25 at 08:11 -0600, Alex Rousskov wrote:
> This is a different issue, but I do not think that limiting access is a
> good idea until the branch becomes stable. When 3.1 is branched (which
> you want to happen soon), there will be a lot of cleanup work still
> going on. I see no reaso
On Thu, 2008-09-25 at 21:12 +0200, Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote:
> > Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
> > Well, I'm a little doubtful but can't argue against that yet.
>
> No, not quite.
>
> There is no point of D
On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote:
> Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
> Well, I'm a little doubtful but can't argue against that yet.
No, not quite.
There is no point of DEVEL releases in the current form of the
development cycle. So we skip th
On Fri, 2008-09-26 at 05:28 +1200, Amos Jeffries wrote:
> The merge queues need to be maintained manually. With this branch there
> are going to be three to process and the more committers, the harder it
> gets to sync them. Thats ignoring Henriks 2.x queues as well for the
> cross-port feature
Alex Rousskov wrote:
On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote:
So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
to some specific daily snapshot? Kinkie+ scheme would use numbered beta
releases: 3.1.0.1, 3.1.0.2, etc.
I think numbered releases are better than
On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote:
> >
> > So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
> > to some specific daily snapshot? Kinkie+ scheme would use numbered beta
> > releases: 3.1.0.1, 3.1.0.2, etc.
> >
> > I think numbered releases are better than
On Thu, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote:
> Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
> Well, I'm a little doubtful but can't argue against that yet.
The progression from DEVELs to PREs to RCs reflects (or should reflect)
the change in one parameter -- code st
On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> Henrik Nordstrom wrote:
> > On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> >
> >> So we have
> >>> 1. Branch when trunk is considered a suitable startingpoint for getting
> >>> to stable, and tag a x.y.0 release at the branchpoi
Henrik Nordstrom wrote:
On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
So I should simply say 'X is how we are doing it'? I think not.
Kinkie has somehow convinced Alex of a different way of numbering then
simply omitting the word 'STABLE', I'm pondering it but need a good
reason to
On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> So I should simply say 'X is how we are doing it'? I think not.
> Kinkie has somehow convinced Alex of a different way of numbering then
> simply omitting the word 'STABLE', I'm pondering it but need a good
> reason to agree.
No, it's si
Henrik Nordstrom wrote:
On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
So we have
1. Branch when trunk is considered a suitable startingpoint for getting
to stable, and tag a x.y.0 release at the branchpoint (or at least set
this version in configure.in).
2a. Release X.Y.0.1 when re
On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> So we have
> >
> > 1. Branch when trunk is considered a suitable startingpoint for getting
> > to stable, and tag a x.y.0 release at the branchpoint (or at least set
> > this version in configure.in).
> >
> > 2a. Release X.Y.0.1 when ready
Hi guys,
I'll be off the Net for the next 3 days, and thus I won't
participate in the follow-up to this discussion.
See you on Sunday!
Kinkie
> On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote:
>
>> trunk (3.1.0)
>> -> sept 30: branch with 10 new features
>> release 3.1.0
>> (makes trunk now 3.2.0)
>> -> oct 30: everything found 'stable'
>> release 3.1.1
>> -> nov 30: 10 new major+ bugs fixed :-(
>> release 3.1.2
On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote:
> trunk (3.1.0)
> -> sept 30: branch with 10 new features
> release 3.1.0
> (makes trunk now 3.2.0)
> -> oct 30: everything found 'stable'
> release 3.1.1
> -> nov 30: 10 new major+ bugs fixed :-(
> release 3.1.2
> (mov
> On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
>> > On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote:
>> >> Cool. So, if there are no objections, we have:
>> >>
>> >> 0) Trunk is usually open for new stuff. Make daily snapshots.
>> >> 1) Branch X.Y when major features are committ
On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> > On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote:
> >> Cool. So, if there are no objections, we have:
> >>
> >> 0) Trunk is usually open for new stuff. Make daily snapshots.
> >> 1) Branch X.Y when major features are committed. Sna
> On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote:
>> Cool. So, if there are no objections, we have:
>>
>> 0) Trunk is usually open for new stuff. Make daily snapshots.
>> 1) Branch X.Y when major features are committed. Snapshots.
>> 2a) Release X.Y.0.0 when all major bugs are fixed.
>> 2
> On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote:
>> On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote:
>>
>> > I only have one question: how well does that release numbering model
>> > match the other OSS projects using the same numbering system? We don't
>> > want to set our own m
On ons, 2008-09-24 at 21:26 +0200, Kinkie wrote:
> The "version X.Y.Z for all Z > W" approach means that it's not easy to
> tell what the state of a release is without knowing what W is for each
> X,Y.
Even then you don't know as the notion of something being stable is very
temporal in nature and
On Thu, 2008-09-25 at 01:21 +0200, Henrik Nordstrom wrote:
> On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote:
> > Cool. So, if there are no objections, we have:
> >
> > 0) Trunk is usually open for new stuff. Make daily snapshots.
> > 1) Branch X.Y when major features are committed. Snaps
On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote:
> Cool. So, if there are no objections, we have:
>
> 0) Trunk is usually open for new stuff. Make daily snapshots.
> 1) Branch X.Y when major features are committed. Snapshots.
> 2a) Release X.Y.0.0 when all major bugs are fixed.
> 2b) Rele
On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote:
>
> > I only have one question: how well does that release numbering model
> > match the other OSS projects using the same numbering system? We don't
> > want to set our own metho
On Wed, 2008-09-24 at 21:26 +0200, Kinkie wrote:
> It's only a psychological thing. .0 "sounds" prerelease. Also the fact
> that devel will not bump the patchlevel release "feels" like slowing
> down and checking things out for the "first" number, 1.
Understood, thank you.
> None of this has (or
On Wed, Sep 24, 2008 at 6:55 PM, Alex Rousskov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2008-09-24 at 17:28 +0200, Kinkie wrote:
>
>> I don't like much not having a fixed "stable" marker much tho, what I'd do
>> is:
>> - when major bugs are fixed, a .0 release point is taken. After that
>> during the
On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote:
> I only have one question: how well does that release numbering model
> match the other OSS projects using the same numbering system? We don't
> want to set our own method and meaning when there is already a common
> way to get confused w
On Thu, 2008-09-25 at 05:00 +1200, Amos Jeffries wrote:
> Just brain dumping at 4am, but, how about this:
>
> stuff goes into HEAD (3-)
> ... after a period we branch (3.1) with features from HEAD
> ... fix all known bugs and release 3.1.0-rc1
> ... if confirmed stable gets officially released as
Alex Rousskov wrote:
On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote:
Alex Rousskov wrote:
On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote:
On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
PRE, to me, means "we think it is stable, what do you think?".
A development re
On Wed, 2008-09-24 at 17:28 +0200, Kinkie wrote:
> I don't like much not having a fixed "stable" marker much tho, what I'd do is:
> - when major bugs are fixed, a .0 release point is taken. After that
> during the stabilization phase, milestones are marked with an
> additional numeral (e.g. 3.2.0.
On Wed, 2008-09-24 at 17:43 +0200, Kinkie wrote:
> > I only have one question: how well does that release numbering model match
> > the other OSS projects using the same numbering system? We don't want to set
> > our own method and meaning when there is already a common way to get
> > confused with
On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote:
> Alex Rousskov wrote:
> > On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote:
> >> On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
> >>
> >>> PRE, to me, means "we think it is stable, what do you think?".
> >>> A development re
> I only have one question: how well does that release numbering model match
> the other OSS projects using the same numbering system? We don't want to set
> our own method and meaning when there is already a common way to get
> confused with.
No standard that I know of - timestamps are quite comm
Alex Rousskov wrote:
On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote:
On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
PRE, to me, means "we think it is stable, what do you think?".
A development release, to me, means "we are done adding features, please
help us with testing a
On Wed, Sep 24, 2008 at 4:45 PM, Alex Rousskov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote:
>> On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
> The DEVEL label is not needed indeed, but I was talking about code
> states. I understand now that you
On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote:
> On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
>
> > PRE, to me, means "we think it is stable, what do you think?".
> > A development release, to me, means "we are done adding features, please
> > help us with testing and polish
Henrik Nordstrom wrote:
On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
PRE, to me, means "we think it is stable, what do you think?".
A development release, to me, means "we are done adding features, please
help us with testing and polishing". And yes, I know that the
definitions at ht
On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
> PRE, to me, means "we think it is stable, what do you think?".
> A development release, to me, means "we are done adding features, please
> help us with testing and polishing". And yes, I know that the
> definitions at http://www.squid-cach
On ons, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote:
> Awaiting a verify:
>http://www.squid-cache.org/bugs/show_bug.cgi?id=2433
Does not look right to me, but a step in the right direction. See
bugzilla.
> Awaiting a verify test and debug:
>http://www.squid-cache.org/bugs/show_bug.cgi
On Wed, 2008-09-24 at 14:34 +1200, Amos Jeffries wrote:
> > Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk
> > code is stable enough to be called PRE at this point, so I was expecting
> > DEVEL. Personally, I would just call it 3.1.0 and categorize it as
> > "development"
> On Wed, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote:
>> >
>> > Lets set a date: 29 September?
>> >
>> > Well, I'll call for a partial hold right now. Please only commit bug
>> > fixes, minor cleanups, and features already on the roadmap for 3.1.
>> > The rest can be queued for commit post
> On Wed, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote:
>> >
>> > Lets set a date: 29 September?
>> >
>> > Well, I'll call for a partial hold right now. Please only commit bug
>> > fixes, minor cleanups, and features already on the roadmap for 3.1.
>> > The rest can be queued for commit post
On Wed, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote:
> >
> > Lets set a date: 29 September?
> >
> > Well, I'll call for a partial hold right now. Please only commit bug
> > fixes, minor cleanups, and features already on the roadmap for 3.1.
> > The rest can be queued for commit post branch.
>
> Lets set a date: 29 September?
>
> Well, I'll call for a partial hold right now. Please only commit bug
> fixes, minor cleanups, and features already on the roadmap for 3.1.
> The rest can be queued for commit post branch.
>
5 days to go and these bits left
* connection pinning
I thi
54 matches
Mail list logo
