headers
Ben Schmidt | 12 Mar 2012 18:30
Picon
Gravatar

Mlmmj 1.2.18a1 released

An alpha release for the upcoming Mlmmj 1.2.18 has been published. Find
it on the downloads page[1]. Please help test it if you can and report
bugs using our bug tracker[2] or here on the discussion mailing list.
Also please report successes to help gain confidence in the quality of
the code. Please also contact me (the maintainer, Ben Schmidt) if you
can help with code review.

This version contains a number of important new features:

- Richer list texts (including a new naming scheme, conditionals,
   automatic wrapping and true UTF-8 support).
- Notifying posters when their posts are being moderated.
- Not-me-too feature to avoid having the poster receiving their own
   messages.
- Ability to explicitly reject posts.
- Ability to explicitly obstruct subscriptions.
- Unsubscribe from all versions of a list at once.
- Ability to switch between different versions of a list by using
   +subscribe[-{digest|nomail|both}] ('both' means normal and digest, and
   is a 'hidden feature').
- A number of bug fixes (including fixing some bugs which could cause
   mail to be lost).
- Improved documentation.

(See the ChangeLog[3] for a more detailed list of changes.)

It is almost entirely backward-compatible. For instance, old list texts
should continue to work. The main backward-incompatible change is that
unsubscribe will now remove a user from all versions of the list, not
just one (no matter which unsubscribe address is used).
(Continue reading)

Permalink | Reply |
headers
Thomas Goirand | 13 Mar 2012 08:16
Picon

Re: Mlmmj 1.2.18a1 released

On 03/13/2012 01:30 AM, Ben Schmidt wrote:
> An alpha release for the upcoming Mlmmj 1.2.18 has been published.

Hi!

Why suddenly changing versionning scheme? Does the "a" means alpha?

Later, if you publish 1.2.18.0, it's going to be considered smaller than
1.2.18a1, so I think it's not a nice numbering scheme (it might break
upgrading in Debian, for example). Something like:

1.2.18.0.rc1

would have been better. Then, you would release 1.2.18.1 ...

Cheers,

Thomas
Permalink | Reply |
headers
Ben Schmidt | 13 Mar 2012 13:14
Picon
Gravatar

Re: Mlmmj 1.2.18a1 released

On 13/03/12 6:16 PM, Thomas Goirand wrote:
> On 03/13/2012 01:30 AM, Ben Schmidt wrote:
>> An alpha release for the upcoming Mlmmj 1.2.18 has been published.
>
> Hi!
>
> Why suddenly changing versioning scheme?

I didn't realise I changed anything.

> Does the "a" means alpha?

Yes, A is for alpha. Followed by B for beta, and RC for release
candidate. That's the system in my head, anyway.

> Later, if you publish 1.2.18.0, it's going to be considered smaller
> than 1.2.18a1, so I think it's not a nice numbering scheme

Well, that depends how you sort, doesn't it? What I've used is a fairly
common numbering system that a lot of packages use, so it wouldn't
surprise me if many sorting algorithms for version numbers dealt with it
OK. A simple ASCII sort won't though, it's true.

> (it might break upgrading in Debian, for example).

I'm not sure that an alpha release should be included in a distribution
anyway, to be honest.

> Something like:
>
(Continue reading)

Permalink | Reply |
headers
Lukas Fleischer | 13 Mar 2012 21:07
Picon

Re: Mlmmj 1.2.18a1 released

On Tue, Mar 13, 2012 at 11:14:26PM +1100, Ben Schmidt wrote:
> On 13/03/12 6:16 PM, Thomas Goirand wrote:
> >On 03/13/2012 01:30 AM, Ben Schmidt wrote:
> >>An alpha release for the upcoming Mlmmj 1.2.18 has been published.

Works fine so far. Didn't notice any regression.

> >
> >Hi!
> >
> >Why suddenly changing versioning scheme?
> 
> I didn't realise I changed anything.
> 
> >Does the "a" means alpha?
> 
> Yes, A is for alpha. Followed by B for beta, and RC for release
> candidate. That's the system in my head, anyway.
> 
> >Later, if you publish 1.2.18.0, it's going to be considered smaller
> >than 1.2.18a1, so I think it's not a nice numbering scheme
> 
> Well, that depends how you sort, doesn't it? What I've used is a fairly
> common numbering system that a lot of packages use, so it wouldn't
> surprise me if many sorting algorithms for version numbers dealt with it
> OK. A simple ASCII sort won't though, it's true.

Yeah, this is used by several projects and shouldn't cause any
trouble... It works under Arch Linux (pacman, which uses a version
comparison algorithm ripped off from RPM):
(Continue reading)

Permalink | Reply |
headers
Ben Schmidt | 15 Mar 2012 12:51
Picon
Gravatar

Re: Mlmmj 1.2.18a1 released

>>>> An alpha release for the upcoming Mlmmj 1.2.18 has been published.
>
> Works fine so far. Didn't notice any regression.

Thanks a lot for the feedback.

>>> Later, if you publish 1.2.18.0, it's going to be considered smaller
>>> than 1.2.18a1

In trying to figure out a better scheme, I disproved it for Debian:

$ dpkg --compare-versions 1.2.18a1 lt 1.2.18.0 && echo YES || echo NO
YES

It's a problem if the final .0 is omitted:

$ dpkg --compare-versions 1.2.18a1 lt 1.2.18 && echo YES || echo NO
NO

That is what I would have done, but due to this issue, I'm happy enough
to include the final .0 as occasionally we do have three-point releases
anyway, and this may be the best solution.

> Yeah, this is used by several projects and shouldn't cause any
> trouble... It works under Arch Linux (pacman, which uses a version
> comparison algorithm ripped off from RPM):
>
>      $ vercmp 1.2.17.0 1.2.18.0
>      -1
>      $ vercmp 1.2.18.0a1 1.2.18.0
(Continue reading)

Permalink | Reply |
headers
Lukas Fleischer | 17 Mar 2012 13:16
Picon

Re: Mlmmj 1.2.18a1 released

On Thu, Mar 15, 2012 at 10:51:02PM +1100, Ben Schmidt wrote:
> >>>>An alpha release for the upcoming Mlmmj 1.2.18 has been published.
> >
> >Works fine so far. Didn't notice any regression.
> 
> Thanks a lot for the feedback.
> 
> >>>Later, if you publish 1.2.18.0, it's going to be considered smaller
> >>>than 1.2.18a1
> 
> In trying to figure out a better scheme, I disproved it for Debian:
> 
> $ dpkg --compare-versions 1.2.18a1 lt 1.2.18.0 && echo YES || echo NO
> YES
> 
> It's a problem if the final .0 is omitted:
> 
> $ dpkg --compare-versions 1.2.18a1 lt 1.2.18 && echo YES || echo NO
> NO
> 
> That is what I would have done, but due to this issue, I'm happy enough
> to include the final .0 as occasionally we do have three-point releases
> anyway, and this may be the best solution.

Oh, I didn't even notice the missing revision/build part. Yeah, should
should include that...

> 
> >Yeah, this is used by several projects and shouldn't cause any
> >trouble... It works under Arch Linux (pacman, which uses a version
(Continue reading)

Permalink | Reply |
headers
Ben Schmidt | 17 Mar 2012 16:52
Picon
Gravatar

Re: Mlmmj 1.2.18a1 released

>> $ dpkg --compare-versions 1.2.18a1 lt 1.2.18.0 && echo YES || echo NO
>> YES

>      $ vercmp 1.2.18a1 1.2.18.0
>      -1

OK. This scheme wins.

Thanks for raising and clarifying the issue, guys.

Ben.
Permalink | Reply |
headers
Quentin Heath | 2 May 2012 18:41

Re: Mlmmj 1.2.18a1 released

Hi everyone,

I know this comes a little late, and I don't really ave the time to
introduce myself right now, but I would like to back on the 1.2.18-a1
/ 1.2.18 proposal. It seems to me that it is the most intuitive and
widely used.
If your only concern is to be compatible with debian's scheme, the
tilde was introduced for this reason: it is the only character smaller
than the empty string, meaning that
  1.2.18~ < 1.2.18 < 1.2.18-
and therefore that
  1.2.18~a3 < 1.2.18~b2 < 1.2.18~rc1 < 1.2.18 < 1.2.18-p1

You can even formally call the package 1.2.18-a1 and give the deb the
number 1.2.18~a1, I don't think anyone would get confused.

As soon as I have more time I will try to do more fundamental contributions.

--

-- 
Quentin
Permalink | Reply |

Gmane