Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releases & semver #363

Open
carlossless opened this issue Oct 28, 2024 · 4 comments
Open

Releases & semver #363

carlossless opened this issue Oct 28, 2024 · 4 comments

Comments

@carlossless
Copy link
Contributor

The README currently states:

Q2PRO doesn't have releases. It is always recommended to use the git master version.

Would you consider changing your stance on this and adopting some release pattern like semver? This would make packaging and distributing q2pro a bit easier.

Furthermore, should the r{xxxx} tags (like r3510) be treated as some form of stable releases?

@carlossless carlossless changed the title Releases & Semver Releases & semver Oct 28, 2024
@skullernet
Copy link
Owner

Releases only make sense if actively supported and maintained. E.g. security fixes are backported, bug reports for these versions are accepted and analyzed, etc. I don't have resources to do that. For this reason only git master version is supported and there are no releases.

Furthermore, should the r{xxxx} tags (like r3510) be treated as some form of stable releases?

I don't think so. These are just random snapshots I make before making some potentially breaking changes to make regression testing easier.

@carlossless
Copy link
Contributor Author

Thanks for answering this!

Releases only make sense if actively supported and maintained. E.g. security fixes are backported, bug reports for these versions are accepted and analyzed

True although, I guess a more minimal approach would be to use it only to signal new features, breaking changes, and bug fixes/patches, without supporting previous versions and backporting fixes to them.

Regardless, I would still like to know if there is any guidance on how to pick the latest stable commit for distribution, or would that always be any recent commit in master?

@skullernet
Copy link
Owner

I guess a more minimal approach would be to use it only to signal new features, breaking changes, and bug fixes/patches, without supporting previous versions and backporting fixes to them.

But that still requires maintaining some kind of changelog, making "releases", etc. For me this seems redundant since you can just take the latest commit and use git history.

I would still like to know if there is any guidance on how to pick the latest stable commit for distribution, or would that always be any recent commit in master?

If this is some kind of rolling release distribution than any recent commit will do I guess. If this is some distribution with fixed release schedule then it's probably better to not package Q2PRO at all rather than providing some outdated snapshot for years.

@carlossless
Copy link
Contributor Author

carlossless commented Oct 28, 2024

If this is some kind of rolling release distribution than any recent commit will do I guess. If this is some distribution with fixed release schedule then it's probably better to not package Q2PRO at all rather than providing some outdated snapshot for years.

While I think that addressing this topic might be helpful for people wanting to package q2pro up anywhere, I am personally interested in having it packaged in NixOS/nixpkgs - NixOS/nixpkgs#286460

The unstable branch/channel could be updated frequently (but I don't see this happening more often than every couple of months), while stable releases happen every 6 months, and only one stable release is ever supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants