branching in packages?

[Ilya N. Golubev]

> If you want to avoid the pre-releases, then M-x list-packages will tell
> you current recommended version as long as you have no pre-release
> archives in the list of download hosts.

This is the trouble: requesting additional information that is not
only ill- defined for automatic processing, but not stored in cvs at
all.  Unlike xemacs core, where all that one needs to obtain current
versions is cvs repository - perhaps even its local copy, in which
case no network transfers are done at all - except automatic
background synchronization of the copy.

Even if have saved, along with xemacs cvs repository copy, (current)
listing of master package download directory, - there is no well-
defined procedure to match its items against tags in cvs.  At least
not one that is obviously automated.  For each package one has to do
the following.

. Determine latest package file name from listing.

. Take package name and version from it.

. Convert it to version tag that *should* be in cvs.  Perhaps it done
the same way for all packages, perhaps not.  If the tag is there, all
right.  What if it is not?

. `cvs update' the package with that tag.

Hope that this is enough to show that obtaining current stable
package sources snapshot is non- trivial.  Having tag like
'current_stable_packages' or some other well- defined markup in cvs
itself would make things much simpler.


> The prerelease cycle is mostly
> intended to catch packaging bugs, not Lisp code bugs.

But used for <Lisp code bugs> way too often.  See package change logs
for statistics.  This is why posted initial message on this subject in
the first place.  Followed up discussion of Lisp code bugs in one
prerelease package: `comint' + `shell' in `xemacs-base'.

Besides, see no clear distinction between <packaging> and <Lisp code>
bugs.  If there are some local Lisp code changes in xemacs package
cvs, and new author / upstream package version is merged, is this
<packaging> operation?  Whatever it is, merging can easily generate
definite <Lisp code> bugs.

> Some package maintainers keep exceptionally unstable packages in the
> unsupported tree

Would be happy to see this practice commonplace.  But currently it is
as described above.