Hi all,
Merging the two large recent threads, my recommendation is as follows:
* The Release Candidates for 1.0 should be bug fixes only.
* Each new Feature, or a Feature Set, goes in a separate branch.
* That branch is tested by those who need/want that feature.
* When testing is completed, the
On March 29, 2007 10:13:37 AM -0500 Eric Rostetter
<[EMAIL PROTECTED]> wrote:
Quoting Charles Marcus <[EMAIL PROTECTED]>:
This is *server* software. If someone is not capable or willing to do
the research to know what the difference between the packages available
are, *regardless* of what numbe
On Thu, Mar 29, 2007 at 10:47:30PM +0100, John Robinson wrote:
> On 29/03/2007 22:27, Axel Thimm wrote:
> >On Thu, Mar 29, 2007 at 09:43:48PM +0100, John Robinson wrote:
> >>[...] If you use ATrpms packages, you
> >>ought to have read the support details (i.e. testing latest software,
> >>works f
--On Wednesday, March 28, 2007 3:46 AM +0300 Timo Sirainen <[EMAIL PROTECTED]>
wrote:
After v1.0 is released, I can finally get back to sane version numbers.
Have the RC's released new features as well as fixed bugs? I've been
hesitant to upgrade to an RC because they seem to be released so
Ejay Hire schrieb:
> I support A. If I get a package from an RPM repository and the version
> number is 1.3, I will think it is better than 1.2.
>
> If I get a package from an RPM repository and the version number is
> 1.3.unstable, I am smart enough to know that it might be "unstable".
No offe
On 29/03/2007 22:27, Axel Thimm wrote:
On Thu, Mar 29, 2007 at 09:43:48PM +0100, John Robinson wrote:
[...] If you use ATrpms packages, you
ought to have read the support details (i.e. testing latest software,
works for Axel, don't complain to him).
No, please do complain to Axel, if somethin
On Thu, Mar 29, 2007 at 09:43:48PM +0100, John Robinson wrote:
> People like me? Again, if you use a RHEL clone like CentOS, you ought to
> have read the support details (i.e. this is a free rebuild, you may rely
> on RH but don't complain to them or us). If you use ATrpms packages, you
> ought
I support A. If I get a package from an RPM repository and the version
number is 1.3, I will think it is better than 1.2.
If I get a package from an RPM repository and the version number is
1.3.unstable, I am smart enough to know that it might be "unstable".
-ejay
On Wed, 2007-03-28 at 21:48 +0
On 29/03/2007 03:41, Eric Rostetter wrote:
Quoting John Robinson <[EMAIL PROTECTED]>:
On 28/03/2007 19:39, Eric Rostetter wrote:
People running Fedora Core run 0.99, and they do not know it isn't
production
(since it comes with FC, which they don't know isn't production).
They ought to; FC
Quoting Charles Marcus <[EMAIL PROTECTED]>:
By the way - what is 'ultruism'? At first I thought it was a typo, but
you did it twice... ;)
I'm very consistent with my typos. ;)
Substitute the word ALTRUISIM where appropriate.
--
Eric Rostetter
The Department of Physics
The University of Texas
This is *server* software. If someone is not capable or willing to do
the research to know what the difference between the packages available
are, *regardless* of what numbering scheme Timo settles on, then they
have no business running a server and/or deserve what they get if they
do so anyway...
Quoting Charles Marcus <[EMAIL PROTECTED]>:
This is *server* software. If someone is not capable or willing to do
the research to know what the difference between the packages available
are, *regardless* of what numbering scheme Timo settles on, then they
have no business running a server and/or
John Robinson wrote:
On 28/03/2007 19:39, Eric Rostetter wrote:
People running Fedora Core run 0.99, and they do not know it isn't
production
(since it comes with FC, which they don't know isn't production).
They ought to; FC in its entirety is devel for RHEL, and this is
prominently pointed
On Thu, 29 Mar 2007 10:30:24 +0200
Nils Vogels <[EMAIL PROTECTED]> wrote:
> TS>
> TS> I don't think packaging is going to be that big of a problem. If
> TS> the packagers can't handle that, then just don't package it.
> TS> Development versions don't really need binary packages anyway..
> TS> And
On Thu, Mar 29, 2007 at 10:30:24AM +0200, Nils Vogels wrote:
> On Thu, Mar 29, 2007 at 02:05:13AM +0300, Timo Sirainen (TS) wrote:
> TS>
> TS> I don't think packaging is going to be that big of a problem. If the
> packagers
> TS> can't handle that, then just don't package it. Development version
On Thu, Mar 29, 2007 at 02:05:13AM +0300, Timo Sirainen (TS) wrote:
TS>
TS> I don't think packaging is going to be that big of a problem. If the
packagers
TS> can't handle that, then just don't package it. Development versions don't
TS> really need binary packages anyway.. And for those using t
Quoting John Robinson <[EMAIL PROTECTED]>:
On 28/03/2007 19:39, Eric Rostetter wrote:
People running Fedora Core run 0.99, and they do not know it isn't
production
(since it comes with FC, which they don't know isn't production).
They ought to; FC in its entirety is devel for RHEL, and thi
On 28/03/2007 19:39, Eric Rostetter wrote:
People running Fedora Core run 0.99, and they do not know it isn't
production
(since it comes with FC, which they don't know isn't production).
They ought to; FC in its entirety is devel for RHEL, and this is
prominently pointed out all over the F we
On 29.3.2007, at 0.03, Frank Cusack wrote:
On March 28, 2007 4:35:50 PM -0400 John Peacock
<[EMAIL PROTECTED]> wrote:
What this model does is to make many more small releases (no more
RC129),
each with a stable feature set.
I don't see how that's different than a/b/rc numbering. You can
On March 28, 2007 5:07:30 PM -0400 John Peacock <[EMAIL PROTECTED]> wrote:
But the argument that numeric only works much better for packagers is
very powerful, IMNSHO...
Yeah, I agree with that.
Frank Cusack wrote:
On March 28, 2007 4:35:50 PM -0400 John Peacock <[EMAIL PROTECTED]>
wrote:
What this model does is to make many more small releases (no more RC129),
each with a stable feature set.
I don't see how that's different than a/b/rc numbering. You can still
cut as many releases a
On Wed, Mar 28, 2007 at 03:46:40AM +0300, Timo Sirainen may have written:
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
I'd really prefer using type b versioning as then there is no ambiguity
when attempting to build packages for dovecot. There are many examples
in the Debian re
On March 28, 2007 4:35:50 PM -0400 John Peacock <[EMAIL PROTECTED]> wrote:
What this model does is to make many more small releases (no more RC129),
each with a stable feature set.
I don't see how that's different than a/b/rc numbering. You can still
cut as many releases as you like.
1.1.0
1
Frank Cusack wrote:
Right, so my point is, you have the same problem and can't tell which
1.3.x is newer than a 1.2.x (on a feature-by-feature or bugfix-by-bugfix
basis). I guess it might not matter. But it's nice to say "use 1.2.5+"
for such-and-such feature and not have to worry that 1.3.0 do
On March 28, 2007 3:59:59 PM -0400 John Peacock <[EMAIL PROTECTED]> wrote:
Frank Cusack wrote:
You misunderstood that. After the release of 1.2.0, 1.1.x is
frozen and development starts again in 1.3.0.
And then how do you release 1.2.1?
This is a well understood process (even/odd development
On Wed, Mar 28, 2007 at 01:39:55PM -0500, Eric Rostetter wrote:
> I go to atrpms or dag wieers or elsewhere, and it might list both devel
> and production ones, but it doesn't say that, it just lists version
> numbers. How am I to know, unless I'm smart enough to go to the original
> web site and
Frank Cusack wrote:
You misunderstood that. After the release of 1.2.0, 1.1.x is
frozen and development starts again in 1.3.0.
And then how do you release 1.2.1?
This is a well understood process (even/odd development). Once 1.2.0 is
released, all new development moves to 1.3.x. 1.2.1 is a
Timo Sirainen schrieb:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
>
> With a) style the releases
On March 28, 2007 8:46:08 AM +0200 Juergen Daubert <[EMAIL PROTECTED]> wrote:
On Tue, Mar 27, 2007 at 11:28:24PM -0700, Frank Cusack wrote:
> Timo Sirainen wrote:
>> After v1.0 is released, I can finally get back to sane version
>> numbers. But any comments on which one is better:
>>
>> a) Postf
Quoting Justin McAleer <[EMAIL PROTECTED]>:
A lot of the posts in this thread seem to be debating between version
numbering and storage layout, which are not mutually exclusive
Yes, but this only addresses the problem at the source, not at the
redistribution point (mirrors, rpm repositories, d
Quoting Chris Wakelin <[EMAIL PROTECTED]>:
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
I don't like this, as the average new user has no idea that the odds
are unstable, and runs them, then gets flamed for it, etc. No matter
how well you document it on the web/wiki, people are g
IMHO unstable versions should never go into packages/ports trees. And if they
do, they should be clearly marked as unstable (in debian sid there're some of
these: the package names are foobar-unstable).
Anyway, keeping development releases separated from stable ones is compatible
with the linux
On Wed, March 28, 2007 3:50 am, Joseba Torre wrote:
> Hi,
>
> El Miércoles, 28 de Marzo de 2007 04:55, Eric Rostetter escribió:
>> Why not just put actual (stable) releases in the "releases/" directory,
>> and
>> put the "unstable" releases in another directory (unstable, testing, or
>> some such).
Timo Sirainen wrote:
After v1.0 is released, I can finally get back to sane version numbers.
But any comments on which one is better:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
With a) style the releases could be done b
On Wed, Mar 28, 2007 at 03:46:40AM +0300, Timo Sirainen wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0
Why not just put actual (stable) releases in the "releases/" directory, and
put the "unstable" releases in another directory (unstable, testing, or
some such).
I think this is the easier way. If it's clear that unstable is unstable (i.e.:
not to be used in production), version numbering is not
Eric Rostetter wrote:
>> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
>
> I don't like this, as the average new user has no idea that the odds
> are unstable, and runs them, then gets flamed for it, etc. No matter
> how well you document it on the web/wiki, people are going to mis
On 28/03/2007 01:46, Timo Sirainen wrote:
After v1.0 is released, I can finally get back to sane version numbers.
But any comments on which one is better:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
With a) style the rel
On Wednesday 28 March 2007 10:48, Magnus Holmgren wrote:
> Also as a packager, I must remark on the ambiguity of (a). Normally letters
> come after numbers in order. Luckily in Debian, it can be transformed
> into "1.1~UNSTABLE.MMDD", where "~" is ranked lower than even the empty
> string.
I a
On Wednesday 28 March 2007 02:46, Timo Sirainen wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
>
On Wed, 28 Mar 2007 03:46:40 +0300
Timo Sirainen <[EMAIL PROTECTED]> wrote:
> After v1.0 is released, I can finally get back to sane version
> numbers. But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unsta
Hi,
El Miércoles, 28 de Marzo de 2007 04:55, Eric Rostetter escribió:
> Why not just put actual (stable) releases in the "releases/" directory, and
> put the "unstable" releases in another directory (unstable, testing, or
> some such).
I think this is the easier way. If it's clear that unstable i
On Tue, Mar 27, 2007 at 11:28:24PM -0700, Frank Cusack wrote:
> >Timo Sirainen wrote:
> >>After v1.0 is released, I can finally get back to sane version numbers.
> >>But any comments on which one is better:
> >>
> >>a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
> >>
> >>b) Odd-even nu
Timo Sirainen wrote:
After v1.0 is released, I can finally get back to sane version numbers.
But any comments on which one is better:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
I like (a) but even better I like 1.1.0{a
Timo Sirainen wrote:
After v1.0 is released, I can finally get back to sane version numbers.
But any comments on which one is better:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
With a) style the releases could be done b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/07 9:46 am, Timo Sirainen wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering:
On Wed, 28 Mar 2007 03:46:40 +0300, Timo Sirainen <[EMAIL PROTECTED]> wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unsta
28.03.07 в 03:46 Timo Sirainen в своём письме писал(а):
After v1.0 is released, I can finally get back to sane version numbers.
But any comments on which one is better:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
With a
On Wed, Mar 28, 2007 at 03:46:40AM +0300, Timo Sirainen wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0
Quoting Timo Sirainen <[EMAIL PROTECTED]>:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
Not my favorite, but works for me. Seems good for Timo, since he
likes to release dated snapshots anyway.
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
I don't like this, as
On 02:46:40 2007-03-28 Timo Sirainen <[EMAIL PROTECTED]> wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0
Aredridel wrote:
>> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
>>
>> With a) style the releases could be done by simply copying a nightly
>> snapshot to releases/ directory and announcing the changes since the
>> last release. I'm not sure if that's good or bad.
>
> For the sake of
On Wed, 2007-03-28 at 03:46 +0300, Timo Sirainen wrote:
> After v1.0 is released, I can finally get back to sane version numbers.
> But any comments on which one is better:
>
> a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
>
> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable
After v1.0 is released, I can finally get back to sane version numbers.
But any comments on which one is better:
a) Postfix-style: "1.1.UNSTABLE.MMDD" -> 1.1.0 (stable)
b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable)
With a) style the releases could be done by simply copying a nigh
54 matches
Mail list logo
