version numbers for release candidates

[Michael Ströder]

HI!

Sometimes many interesting changes are solely in RE24 and releasing the next
true release takes some time. During this period I'd love to see pre-release
version numbers assigned to RE24.

Especially in case Quanah sends out an inquiry for another RE24 test round
something like currently 2.4.41a1 or 2.4.41b5 or 2.4.41rc42 could be assigned
(see http://semver.org/).

This would make it possible to package RPMs etc. of pre-releases with
non-conflicting version numbers which get replace by the real release package
later. And for test rounds everybody would test the same snapshot.

What do you think?

Ciao, Michael.

[Howard Chu]

Content preview: Michael Ströder wrote: > HI! > > Sometimes many interesting
changes are solely in RE24 and releasing the next > true release takes some
time. During this period I'd love to see pre-release > version numbers assigned
to RE24. > > Especially in case Quanah sends out an inquiry for another RE24
test round > something like currently 2.4.41a1 or 2.4.41b5 or 2.4.41rc42
could be assigned > (see http://semver.org/). > > This would make it possible
to package RPMs etc. of pre-releases with > non-conflicting version numbers
which get replace by the real release package > later. And for test rounds
everybody would test the same snapshot. > > What do you think? [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: semver.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP development discussion list <openldap-devel.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-devel/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-devel-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=subscribe>
Errors-To: openldap-devel-***@openldap.org
Sender: "openldap-devel" <openldap-devel-***@openldap.org>
X-Spam-Score: -4.2 (----)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: Michael Ströder wrote: > HI! > > Sometimes many interesting
changes are solely in RE24 and releasing the next > true release takes some
time. During this period I'd love to see pre-release > version numbers assigned
to RE24. > > Especially in case Quanah sends out an inquiry for another RE24
test round > something like currently 2.4.41a1 or 2.4.41b5 or 2.4.41rc42
could be assigned > (see http://semver.org/). > > This would make it possible
to package RPMs etc. of pre-releases with > non-conflicting version numbers
which get replace by the real release package > later. And for test rounds
everybody would test the same snapshot. > > What do you think? [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: semver.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Michael Ströder
HI!
Sometimes many interesting changes are solely in RE24 and releasing the next
true release takes some time. During this period I'd love to see pre-release
version numbers assigned to RE24.
Especially in case Quanah sends out an inquiry for another RE24 test round
something like currently 2.4.41a1 or 2.4.41b5 or 2.4.41rc42 could be assigned
(see http://semver.org/).
This would make it possible to package RPMs etc. of pre-releases with
non-conflicting version numbers which get replace by the real release package
later. And for test rounds everybody would test the same snapshot.
What do you think?

I would rather see more responses to the calls for testing so we can identify bugs faster and get real releases out faster.

In the meantime, it would be a good idea to include the git revision in each call for testing.

[Michael Ströder]

Post by Howard Chu

Post by Michael Ströder
HI!
Sometimes many interesting changes are solely in RE24 and releasing the next
true release takes some time. During this period I'd love to see pre-release
version numbers assigned to RE24.
Especially in case Quanah sends out an inquiry for another RE24 test round
something like currently 2.4.41a1 or 2.4.41b5 or 2.4.41rc42 could be assigned
(see http://semver.org/).
This would make it possible to package RPMs etc. of pre-releases with
non-conflicting version numbers which get replace by the real release package
later. And for test rounds everybody would test the same snapshot.
What do you think?

I would rather see more responses to the calls for testing so we can identify
bugs faster and get real releases out faster.

I'm definitely the wrong person to blame for not testing RE24.

Post by Howard Chu
In the meantime, it would be a good idea to include the git revision in each
call for testing.

The problem when creating RPM version numbers directly based on git revisions
is the lack of proper ordering.

But some issues arise when trying to push the source through the distributions
standard build environment.

Ciao, Michael.