[Date Prev][Date Next]
Re: ITS#4787: Download links with version vs. date
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
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
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:
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
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.
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
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
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
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
And frankly no-one remembers the release
dates. Especially since also CHANGES does not contain the release
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.