Create Tagged Releases

[tajmone]

Creating tagged releases was already discussed in #24:

@fantaisie-software:

I was planning to tag master at every release, so we get a track of the history and can get back to a specific version.

... so this is just a reminder as a independent Issue.

Being able to checkout specific releases via tags would allow third party projects to automate various task involving assets from this repository, e.g.:

• Downloading updated Licenses files (from the Documentation/ directory, via license_application.txt, etc.) to ensure that custom applications always include the correct third party components licenses associated with the PureBasic version used by the project.
• Access the latest PB keywords (e.g. for syntax highlighters' definitions) by fetching the correct version of KeywordsData.pbi, which can be used to extract the keywords list and automate updating PB syntax definitions via some scripts or template, etc. (possibly, this won't work for SB, since the repo will probably only tag PureBasic releases)
• Many other tasks which depend on being able to checkout by tags instead of commits (which can't be programmatically determined).

... which would be rather cool, and greatly simplify maintenance work for such projects (of course, I'd be the first one to benefit from this, since I've a few PB repositories which could be automated via tags).

[fantaisie-software]

How do you see the steps for a release @tajmone ? What I was thinking was:

1. Merge devel into master
2. Tag master with current PB version
3. Use the tag as repo for the build server

Now, can we do a fix on a specific tag ? Imagine we have 6.00 LTS and a 6.10 released. We want to do a 6.01 LTS, how do we proceed ? Is it possible with a tag, or do we need a real branch ?

[tajmone]

Your suggestions are correct, the goal is to be able to pin-point the exact commit that introduces a version bump.

Now, can we do a fix on a specific tag?

I'm not sure what you mean by fixing. Each tag (hard tag) corresponds to a GitHub release, so once created a release shouldn't be amended, instead a new one created (e.g. a bug fix would require a new patch release).

Imagine we have 6.00 LTS and a 6.10 released. We want to do a 6.01 LTS, how do we proceed ? Is it possible with a tag, or do we need a real branch ?

You can name the tags whatever you like, after all PB uses its own version scheme, not Semantic Versioning. So tags like 6.01-LTS, 6.02-RC (release candidate), etc. are all fine (and also common with Semantic Version releases too).

Since releases are tag-based they point to specific commits, not branches. So you can create a release from any branch, provided you don't delete or force push the branch in the future. So, depending on how you merge from devel into master, you could create stable releases from commits that are merged into master, and other releases from devel. In this case, maybe it's better not to squash commits into master, just to avoid entanglements that could result in devel requiring to be rebased.

So the only rule should be to ensure that any branches that contain releases are neither deleted, nor rebased (or other operations involving history rewrite). The devel branch has been the reference baseline so far for all developers, so I would say it's safe to assume that we're accustomed to keeping it clear from history rewrites.

Another safe strategy for tagged released that are not from master could be to create a branch from devel whenever a release is due, and create the tag on its branch head, and then just leave it as it is, so it would survive even if a rebase is necessary — if the branch is named like the release tag (or release_6.01, for example) it shouldn't create confusion, since it become obvious what it is.