please use tags/version numbers that make it clear what is a beta and what is a general release

[kanavin]

Hello, we (Yocto project) update versions in an automated fashion by checking upstream version tags and matching them against a regex (when needed) - it becomes therefore impossible to tell that e.g. 600 is actually a beta without manual human checks against mailing list archives:

https://www.mail-archive.com/[email protected]/msg00049.html

or project page: http://www.greenwoodsoftware.com/less/download.html

Can you please mark betas as such inside the tags and tarball filenames?

[kanavin]

We have already updated to 600 by the way, none of us having been aware that it's a beta :(

[polluks]

Indeed, https://github.com/gwsw/less/releases is empty. It's waiting for 590.

[rossburton]

Is there a numbering scheme in use? For example, is 600 a beta just as 700 will be a beta, so we can skip any release which is a round hundred?

[gwsw]

You should never pull release versions from github. All github versions should be considered to be betas. Release versions are distributed on greenwoodsoftware.com. That said, some packages on greenwoodsoftware.com are also betas. There is no numbering scheme because at the time a release is built, I don't know whether it will survive the beta process. But the current release version number will be in https://greenwoodsoftware.com/less/release.txt. Does that address this issue?

[kanavin]

Not really. The upstream checker we use is pulling down html pages from projects' websites where the links to the tarballs are, and parses "a href" tags to extract the tarball names, match them against a tarball regex, and then pick the latest version from the matches. We'd have to special-case a plaintext fetch, just for determining the latest less version.

Would it be possible for you to additionally tag the stable releases in git using e.g. a separate 'release-590' format for the tag or similar?

[gwsw]

Hm, I'm not quite following how the suggestion in your second paragraph addresses the algorithm you describe in your first paragraph. In your first paragraph, it sounds like you're just parsing the html page from greenwoodsoftware.com and looking for the largest version number mentioned in an href. I don't see how git tags would influence this algorithm. If I upload version beta version 600 to greenwoodsoftware and link to from index.html and download.html, it seems to me that your algorithm will immediately think that it's the latest release, regardless of what git tags exist. Am I misunderstanding something?

[kanavin]

Sorry, the description for how we determine the versions was incomplete. If the source code is obtained from a tarball download, the version check goes how I described. If the source code is pulled from git, the version check lists all tags with 'git ls-remote', matches them against a 'version regex', and sorts that filtered list to find what the latest version (and corresponding commit id) is. So yes, we'd have to switch to git fetching, but appropriate tagging would ensure only stable releases would be built.

[kanavin]

For example, here's how it's stipulated for gdb:

UPSTREAM_CHECK_GITTAGREGEX = "gdb\-(?P<pver>.+)\-release"

So it lists all tags that match that regex, and the part in the middle is the version: https://sourceware.org/git/?p=binutils-gdb.git;a=tags

[gwsw]

Ok, but as I said, release versions of less are tarballs downloaded from greenwoodsoftware.com. It would be possible for me to add a tag on github which you would use to determine the version number, and then you would go to greenwoodsoftware.com to download the tarball. But it seems a little convoluted to use github solely to get the version number, especially when it is already available on greenwoodsoftware.com. But if that's what you want to do, I guess I can add a git tag when a version becomes a non-beta release.

[kanavin]

If we check git tags, we then download the source by cloning from git. If we check the webpage, then we download the source by fetching a tarball. We do not cross from one to the other, and treat both ways to get the source as equal. A lot of projects don't even release tarballs nowadays and mark a release only by adding a tag.

The problem with less releases is, neither the git tags nor the tarball filenames currently contain any indication of what is a beta and what is not. So if there's a dedicated release tag on git, we'd clone that revision, and that revision only. If the tarball filename would be, e.g. less-590-release.tar.gz, we would be able to catch that too.

[gwsw]

Well, as I said earlier, releases should be downloaded from greenwoodsoftware.com, not from github. So from what you're saying, any information about what is a release should come from greenwoodsoftware.com, not from git. You don't like the release.txt idea, so how about if I make a second link to the tarball when a release becomes official? So, for example, less-600.tar.gz currently exists as a beta version. If it were to become an official release, at that time I would add a link less-600-release.tar.gz pointing to the same file. And I guess for your tool to work, I would also need to add an href in an html file somewhere that points to this new name?

[kanavin]

That's right, that would work.

[Saklad5]

@gwsw Right now, new releases of less are announced through a simple HTML page and a mailing list. I feel providing an Atom feed would be very helpful for keeping tabs on new versions, especially given all the new features that have been added since the last stable release.

Mailing lists are a lot harder to work with, and impose a much greater burden on the operator than simply hosting an easily-cached feed on the website. GitHub actually auto-generates an Atom feed for new tags in a repository, but you've made it clear these tags are all betas. Besides, I consider that a poor substitute for a bespoke news feed.

[gwsw]

Perhaps a solution would be appending -beta or -release to each tag name. Then the existing github atom feed would have the information you want. So far in response to this issue I have only changed the tar file names. Changing the tag name as well would propagate the beta/release information into the github feed.

[Saklad5]

I mean, I'd rather have the actual news with announcements intended for humans, like you'd get through the mailing list.

I am relatively confident whatever you are currently using to run the mailing list has options for generating a feed as well. They usually do.

[piotr-dobrogost]

Perhaps a solution would be appending -beta or -release to each tag name.

This sounds like a good idea. No need to use both, however. Use beta for betas and plain version for releases; that's the way people usually do.

[Saklad5]

Perhaps a solution would be appending -beta or -release to each tag name.

This sounds like a good idea. No need to use both, however. Use beta for betas and plain version for releases; that's the way people usually do.

I mean, that's because they usually use Semantic Versioning.

[gwsw]

The original issue has been addressed. Beta releases are named less-NNN-beta.tar.gz and production releases are named less-NNN.tar.gz. If anyone thinks an atom feed is desirable in addition to this, please open a new issue for that.