milkypostman/melpa — pull request #1771 by jorgenschaefer (2014-06-15 12:38:07+00:00)
Title: Suggestion: Adding timestamped packages to MELPA stable as a fallback

MELPA stable was an excellent move. There is one problem with it at the moment, though. As it is missing a lot of packages, it's not uncommon to have to add MELPA unstable to the archive list to get some packages otherwise not available. But at that point the packages in unstable override the packages in stable, making stable quite moot. I was thinking about ways to fix/work around this, so you can have stable packages when available, but unstable ones as a fallback.

One approach would be to add unstable packages to stable, but only if there are no release tags yet. This would add packages to MELPA stable that would not be there otherwise, but still allow authors to tag stable releases. This requires unique, timestamp-based version numbers that can be overridden by later releases.

To get those, when a package does not define any tags, MELPA would try to guess the version of the package from the file header or -pkg.el file, and _append_ the timestamp version to that. For example, a package that has a `;; Version: 1.2` header (but no tags), it would get a version in MELPA stable of `1.2.20140615.657`. This still allows unique versions dependent on modification times, but it also allows the package to declare an actual release which would then be higher than the timestamp version.

This way, there would be a number of packages in MELPA stable that are not actually declared stable by their authors, but the alternative would be for them _not_ to be in the repository, where I think having them at all is preferable. As soon as an author declares a stable release, this will override any of the prior unstable versions.

This PR is a quick attempt at adding the feature as described above. A test run locally created 1304 packages in MELPA stable with sane-looking version numbers (at least if e.g. `bf-mode-0.0.1.20130403.1642.el` can be considered "sane-looking" :-)), almost tripling the available packages without overriding stable packages.

Does this sound like a useful idea? If yes, I'd be happy to clean up the code further if required. I'd also be interested in extending this to non-git fetchers if you are interested. If there are problems with this approach, I'd be happy to help try and find a better solution for the problem.

Thank you for the consideration.