The reasons for versioning is for more explicit human and machine-readable knowledge of the state of the world a Forem is in. It helps us tag exactly what might be wrong or vulnerable with any particular Forem instance.
I imagine whatever system we go with would be "our flavor" of that system, where we'd want to document our approach for the betterment of admins and community members' experiences.
Thoughts?
Top comments (8)
I am a big fan of using update streams like Fedora CoreOS does:
docs.fedoraproject.org/en-US/fedor...
getfedora.org/en/coreos?stream=next
They have three streams: stable, testing, and next. Within each stream they release version with a date string
31.20200517.3.0for example. This version number has information about the build that is pretty meaningful.We should adopt something similar for our builds with streams such as
stable ==> beta ==> edge. This way we can have different risk thresholds for users to consume Forem which would allow for some to opt in for more stable builds but less new features and bug fixes vs more possible bugs but new features and bug fixes.Big fan of dates here instead of arbitrary numbers, though I understand the psychological effect of 1.0 and so on.
A lot of products do the "streams", those channel releases for Chrome or Firefox where you can be on stable, beta and nightly/canary or whatever.
The other link to this is the SLA that has to be attached to those three channels (or update streams?).
What SLA is attached to stable, how long a version is supported?
What SLA is attached to beta if any?
We could also adopt the concept of LTS like Ubuntu, Node and others.
PostgreSQL for example has a public versioning policy which is summed up to "5 years after its initial release" postgresql.org/support/versioning/ - but that could be overkill for a web app, as it's not a database.
Are we good with supporting older versions for months or years? What about security fixes? How do we apply security patches to older versions?
The complication here is that we're going to have both the managed version which likely will mostly be installations on the stable version until the next release and the self install version.
Mostly questions and ideas than answers as you can read :D
I feel like there's probably got to be a concept of what we are doing right now, and what our plan is for the future.
Like... For now, I'd say we should really move full steam ahead and not try and support old versions, create a culture that you need to get up to date. In the future we should have a more thorough and forgiving approach.
I think our approach and plan for security patches is a wholistic discussion we should have in the near future. I have some thoughts here.
I also like the dates a lot. The one thing I really want for practical purposes in the near future is to print the version in the footer— Especially while we're in the "sloppy" phase of our processes here. It really helps to be able to eyeball what version of the site is running, along with an endpoint like
/api/metafor info like that. All in all the human readability of the date is really practical, especially because unlike a pure computer-consumption API, changes to our site have so much human emotional consideration if we make a choice, ship a design tweak, etc. The humans should be able to see that we're on the version that shipped such and such date.Along those lines, it might be nice if we established a "nickname" protocol for our releases. I'd be supportive of a "Friends"-esque naming convention. 😄
"The One Where We Accidentally Broke Connect"
"The One Where We Accidentally Broke Connect Again"
"The One Where We Finally Fixed Connect"
I like this idea. I tend to adopt things before they are ready so having a beta / edge build would be ideal.
I think the key to good version is simplicity. It doesn't matter how clever a versioning scheme is if no one can communicate how it works in simple words.
Good call. Especially because of how human-centric the product is. Not like this is just an API for communicating with another computer.
In gaming we do a year.increment
EX:
2020.1rc
2021.123b
2040.1902034p
where .1 increments. and the year increments. a = alpha, b = beta, rc = release candidate, p = production
you could add in which quarter its released. This is helpful if you maintain a seasonal theme etc..