Create 1.5 and 1.5.16 stable tracs for "metanorma"

store-requests
#1

Hi, could a store admin please create 1.5 and 1.5.16 tracks for “metanorma” snap

#2

Hi! Metanorma has no existing tracks, so per Process for aliases, auto-connections and tracks , we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have a few questions before casting my vote.

  1. What’s Metanorma’s release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream?
  2. Is there some commitment from upstream on maintenance of old versions?
  3. Are new versions backwards-incompatible? meaning, if I was running e.g. version 1.5.15 and try to install 1.5.16, will that just work, or do I need to migrate my data/configuration, or will things break horribly? Similarly, what’s the backward-compatibility story between e.g. 1.5 and 1.6?

Thanks!

  • Daniel
#3

What’s Metanorma’s release cadence, how often is a new version (potentially requiring a new track) released?

Usually, we release a new version in a 1-2 weeks

is this documented somewhere by upstream?

There is no release plan/schedule or something like this

  1. Is there some commitment from upstream on maintenance of old versions?

Usually no, we need version track just in case to allow users rollback to previous version

We are trying to follow semver.org approach.

if I was running e.g. version 1.5.15 and try to install 1.5.16, will that just work Similarly, what’s the backward-compatibility story between e.g. 1.5 and 1.6?

For both questions answer is yes. it will just work, no migration need, in case of configuration change will need, tool will check this and do migration to new config format

#4

Hi there,

Tracks are primarily meant to allow users to choose to stay on an older release, mainly because existing data is incompatible with the newer version of your software. If as you say typically versions are backward-compatible, it doesn’t look like users would have a compelling reason to choose, say, 1.5.15 over 1.5.16 (or even 1.5 over 1.6). In this case, tracks would only add an additional burden to your users since they now have to figure out which track works for them, choose it, and then make sure it’s kept up to date with security fixes and other updates; it’s also more burdensome for you because instead of just publishing to stable and having users update automatically, you now have to publish potentially different revisions in different channels and educate your users on how to choose the correct one.

Users can roll back to previous revisions they had installed, and as a publisher you can either republish an older release to stable, or create a branch with an older release if a user reports they need to install that for any reason (branches are temporary but would allow for a workaround while, for example, an issue is found and fixed on the stable release).

I would suggest reading this explanatory blog entry (and its part 2, linked there as well) to understand how to use channels and tracks. If after that you still feel you would benefit from using tracks, please let me know and I’ll gladly create the tracks for you - it’s just that based on what you explained I don’t think you would need them in any case.

  • Daniel
1 Like
#5

Thanks a lot for the explanation, probably you are right, thacks doesn’t looks like a right solution