On Oct 11, 2007, at 8:27 AM, Michael Ströder wrote:

Hope it's ok to take this to openldap-devel.

Seems more of a release practices issues than a development issue, so I would suggest it be discussed on the committers list. This topic is a rathole.

Kurt Zeilenga wrote:

...

ITS#4787: requests change in "stable" release naming. More discussion needed. (I oppose making this change for various reasons).

What are these "various reasons"?

First off, I don't anything is broken here. You, and possibly others, just don't like the naming convention. Naming conventions are such that somebody won't like which ever is chosen. Someone has to make a choice and run with it. That choice was made long ago. Once the choice has been made, unless there is a strong reason to change, conventions should not be changed.

I don't see a strong reason to change. You describe some only potential problems. The list archives seem to support a conclusion that there is no significant actual problems due to the current naming practice.

I also note that changing naming conventions will naturally induce significant problems. These problems seem far more significant than the potential problems you outline.

In particular, if someone where to see: openldap-stable-2.3.38.tgz openldap-stable-2.4.N.tgz

That 2.3.38 is the "stable" 2.3 release and 2.4.N is the "stable" 2.4 release. However, there is, at any one time, only one "stable" release (see the FAQ)... not one per branch. The release of openldap- stable-2.4.N.tgz means that openldap-stable-2.3.38.tgz is no longer the most stable version available, 2.4.N is the most stable.

The current naming convention reflects that what is considered the most stable release, at any date, is not branch specific.

Let me address your specific points (from ITS#4787):

1. Common practice in other open source projects is to create file

names with dates only for CVS/SVN snapshots.

s/Common practice in other/A common practice in some other/ There are many common practices. There is not one single common practice. Anyways...

The OpenLDAP Project practices stems from the days when we laid OPENLDAP_STABLE_date tags in CVS. openldap-stable-date.tgz was a "snapshot" of that tag.

Today, the Project no longer has separate OPENLDAP_STABLE_date tags as we always move OPENLDAP_STABLE forward to a OPENLDAP_REL_ENG_x_y_z tag. But openldap-stable-date.tgz name still reflects the date in which we moved OPENLDAP_STABLE forward. The Project just don't bother laying the redundant tag, and generating a redundant tarball.

So it might be hard for beginners to recognize that these files are really stable releases even though the string "stable" is also in the file name.

Most anything *might* be hard for beginners. But have we any report of an actual problem here? or anything indicating anyone had an actual problem?

I note that only one release is considered "stable" at any given time, openldap-stable.tgz always points to it. (openldap-release.tgz always points to the current release). When someone is looking for THE "stable" release, it's fairly easy for them to recognize that openldap-stable.tgz or the openldap-stable-latestdate.tgz is the right one to grab.

One might argue that openldap-stable-date.tgz symlinks are not needed, we could just move openldap-stable.tgz forward when OPENLDAP_STABLE is moved forward. But given the history, I see no reason not to continue creating the date symlinks.

Note that these .tar.gz files could be obtained from another source, not directly from the official download page.

As do the more commonly used openldap-release.tgz and openldap- stable.tgz symlinks. But I've heard anyone report a problem because of this.

2. On the mailing lists always the version number is referred/

proposed. But this does not appear in the file name.

Yes, but is here any evidence that a person downloading from any of the symlinks has not been able to provide the version number on the list?

And frankly no-one remembers the release dates. Especially since also CHANGES does not contain the release dates. So the only mapping is the download page.

Has this it lead to an actual problem?

3. Common practice is that the root directory name within

the .tar.gz matches the exact version in the .tar.gz file name.

Your suggested naming wouldn't cure this.

Also, the root directory name not matching hasn't, to the best of my knowledge, caused any problems. Note that openldap-release.tgz and openldap-stable.tgz, which are frequently downloaded, also have names which don't match the root directory name. I cannot recall issues arising from their naming.