Project Releases Using PB Version as Tags

[tajmone]

Hi @SicroAtGit,

I was thinking of waht you said, about the fact that the CodeArchiv should only host code that runs with the latest version of PureBasic. I totally agree with this, and I've come to the conclusion the best way to handle release tags would be as follows:

• release tags should matche the PureBasic version, eg: v5.61
• whenever a new version of PB is releases, the current state of master branch is tagged with the previous PB release.

This means that each tag will represent the latest commit for any given version of PB. After a new version of PB has been released (and a project release created) then all the work of checking and adapting the code against the new PureBasic version begins. Any incompatible code is either updated or removed (temporarily or permanently), and so on until the next PB version/repo tag.

The idea is that release tags would allow to quickly switch to any given PB version number and access all the files of the project as they were at the time they were working for that version. This could become useful in the years, for example if I'm looking for some code no longer availabe with new PB versions (for some reason or another), or because I need a specific version (eg: Scintilla was updated and the code is incompatible, ecc.).

It would also make it easier to port old code which was abbandoned.

I had the same problems with my PB Archives project: because of the mixture of different codes it contained, the only release tags that would make sense were either these or arbitrarily making a release a specific points in time (eg: every 1st of January, and create yearly snapshots; or every so many months).

In theory there is total freedom in how tags are used, and one could adopt both systems. But in practice, consistency is best and the only true reference in this context is the PB version for which the codes are granted to work with (which of course, forces to create tags at the end of a PB version cycle, rather than at its beginning).

What's you view on this?

[SicroAtGit]

The idea is good. I've thought about that, too.

Once the archive has reached a satisfactory state, we can implement the release tags.

It must be decided whether the LTS versions of PureBasic should also be considered.

[tajmone]

In theory LTS versions should just benefit from their base version tag, which could mean sticking to and older commit point in time if PB version has moved forward since. After all, LTS versions should only deal with bug fixes, not new features, right?

I personally would keep updating code only for the latest release, especially since PB has rather few and long stretched LTS releases. Again, in theory one could update the previously tagged commits by either moving the tags to a newer commit or by using branches. Either way, I think that it would complicate maintainance for a project whose main aim is to preserve and update a series of codes which would otherwise probably go lost. But if someone where to contribute updates to older or LTS tagged commits, one could make space for them by adding an appendix to tag (eg: v5.60, v5.60.b, v5.60.c, or something along thos lines, to indiciate succession within the same release but without moving tags around).

[SicroAtGit]

Okay, I agree.

There is still some work to be done on the code archive. In the near future I will create issues for the upcoming work and summarize them in a milestone.

When the milestone is completed, the code archive will be in a mature state and ready for the PB version tags.