Axel Thimm wrote:
How about using a version scheme starting with "2.0"? If there is a
pigeonhole for each 2.0.x release, then
dovecot-2.0.x.tar.bz2
dovecot-pigeonhole-2.0.x.tar.bz2
could be the released pairs.
That's the problem. Timo and I do not release new versions
synchronously. Only wh
On Thu, Apr 08, 2010 at 12:09:27PM +0200, Stephan Bosch wrote:
> Axel Thimm wrote:
> >As a (downstream) packager I have some questions:
> >
> >a) pigeonhole is called a working title - will the final release
> > be called something else like dovecot-sieve again?
>
> Well, I was a bit uncertain a
Axel Thimm wrote:
As a (downstream) packager I have some questions:
a) pigeonhole is called a working title - will the final release
be called something else like dovecot-sieve again?
Well, I was a bit uncertain about the name. People who don't know what a
pigeonhole is or what the verb me
On 07/04/10 21:08, Axel Thimm wrote:
> b) The versioning seems to go from 0.1.15 to 0.1.13. From a packager's
>POV it would be better to allow a natural version upgrade
>path. Perhaps the version in hg is just not updated?
Since -sieve and -managesieve codebases have been merged, the ideal
On 07/04/10 21:08, Axel Thimm wrote:
> b) The versioning seems to go from 0.1.15 to 0.1.13. From a packager's
>POV it would be better to allow a natural version upgrade
>path. Perhaps the version in hg is just not updated?
Since -sieve and -managesieve codebases have been merged, the ideal
Hi Stephan,
many thanks for all the work you do on the new sieve parts to dovecot.
As a (downstream) packager I have some questions:
a) pigeonhole is called a working title - will the final release
be called something else like dovecot-sieve again?
b) The versioning seems to go from 0.1.15 to