Versioning Proposal
ZimCodes opened this issue · 13 comments
This is a proposal for following the semantic versioning in hopes of reducing speed of the MAJOR component.
Semantic versioning Reference:
MAJOR.MINOR.PATCH-PARTIAL
I've noticed that when a new feature, which only contains a set of new themes, gets merged into the main branch it automatically receives a MAJOR number increase. The problem is, as time moves on, this speedy increase in versioning will place Doki Theme Web to version 30.0.0 by next year (an exaggeration, but the idea is still there).
By semver specification, the feature containing only a set of themes would be considered a backwards compatible change. Thus 1.0.0 would now be 1.1.0 instead of 2.0.0. Only Non-backwards compatible or breaking changes would be able to increment the version to 2.0.0.
So I propose following more closely to the semantic versioning specification or something like the following instead:
YEAR.MAJOR.MINOR
YEAR.MONTH.DAY
30.0.0 by next year
The JetBrains plugin is already on 22.0.2 😂
Anyways, what I want is something consistent across all platforms, and not just have this platform be different.
I think what I might switch to is
YEAR.THEME-RELEASE(.MINOR)
Say for instance the next set of themes get created, the version will be 2022.1, that way all platforms are on on the same version. If any bug fixes are needed, then it would be 2022.1.1, that way I know that all versions, across all platforms, with 2022.1 have the same themes. Just haven't thought about what I would do for breaking changes (Maybe those would be lumped into theme releases?)
Just haven't thought about what I would do for breaking changes (Maybe those would be lumped into theme releases?
That’s one way. Other ways could be:
YEAR.THEME-RELEASE.MAJOR(.MINOR)
YEAR.THEME-RELEASE.MAJOR(-MINOR)
So 2022.1.1.1 or 2022.1.1-1.
I'm leaning more towards YEAR.THEME-RELEASE.MAJOR(.MINOR)
However, the more I think about it, I feel that semantic versioning really doesn't apply nicely to theme plugins (code libraries, sure). Is dropping support for older version platforms a breaking change? Users still using the old platform won't really know the difference until they upgrade platforms and get a new version.
What I want is something consistent such that all versions of plugins, across current supported platforms, could potentially line up. I feel that the YEAR.THEME-RELEASE.MAJOR(.MINOR) would work, omitting any values that are zero. So that we don't start off with 2022.1.0.0, but we could we have 2022.1.0.1 ?
I believe you should think in terms of the plugin itself and not the platforms it supports.
For instance, Doki Themes currently supports Firefox, Edge, & Chrome. If down the road there is an announcement that Firefox would no longer be supported, you have to think what does that entail?
This entails that:
a. Firefox will no longer receive updates of any kind (security, patches, feature, etc).
b. Firefox will be removed from the project at some point as it is no longer in development.
c. The latest Doki Theme for Firefox version will now may or may not work for the latest Firefox browser.
d. Along with others...
Is dropping support for older version platforms a breaking change?
In this regards to this, most likely.
I feel that the YEAR.THEME-RELEASE.MAJOR(.MINOR) would work, omitting any values that are zero. So that we don't start off with 2022.1.0.0, but we could we have 2022.1.0.1?
I'm cool with this versioning choice if this is chosen.
I believe you should think in terms of the plugin itself and not the platforms it supports.
Ah, I probably should emphasized this point:
Anyways, what I want is something consistent across all platforms, and not just have this platform be different.
I was talking about adopting a new versioning standard for all of the other plugins, and not just the Firefox plugin.
I like YEAR.THEME-RELEASE.MAJOR(.MINOR) because I know I have the same themes if I am using doki-theme-hyper 2022.1.0.3 and doki-theme-vim 2022.1.
The only thing that I am hung up on is I drop support for older platforms all the time (like I used to support Visual Studio 2019, but dropped it in favor of Visual Studio 2022), I don't know the best way to represent that change with YEAR.THEME-RELEASE.MAJOR(.MINOR) , while still knowing what themes are included in the release. Each theme release appears to have its own major/minor versions which could indicate breaking changes, say 2022.1.0.0 was release, then 2022.1.1.0 was released and dropped support for older version of the platform, but then 2022.2.0.0 comes and there isn't a way to tell that the breaking change happened in the previous theme release.
Anyways, I'll think about it some more, nothing is written in stone, and I can always change what I started too :)
I was talking about adopting a new versioning standard for all of the other plugins, and not just the Firefox plugin.
I am also thinking in this manner as well.
say 2022.1.0.0 was release, then 2022.1.1.0 was released and dropped support for older version of the platform, but then 2022.2.0.0 comes and there isn't a way to tell that the breaking change happened in the previous theme release.
Interesting! I very much appreciate the explanation as I now have a clear grasp on the issue.
A solution could be:
YEAR.THEME-RELEASE-MAJOR.MINOR(.PATCH)=2022.1-1.0.0or2022.1_1.0.0or2022.1-v1.0.0or2022.1_v1.0.0
This version format differentiate two contrasting versionings which are now grouped together: YEAR.THEME-RELEASE and MAJOR.MINOR(.PATCH). In this way, the two versions can be updated & handled separately from each other across all the various platforms Doki Theme supports.
How about this?
THEME_MAJOR.THEME_MINOR-MAJOR.MINOR.PATCH
It's essentially just 2 versioning systems smushed together, one for the theme and then one for the plugin
In the context of doki-theme-firefox the plugin starts off with this version 18.0-1.0.0, and then this is a made up changelog:
- Fixes a color usability in the doki-theme-definition
18.1-1.0.0 - Adds a feature that randomly changes the current theme every 2 hours
18.1-1.1.0 - Adds a new theme
19.0-1.1.0 - Fixes a bug in new random theme changer feature
19.0-1.1.1 - Drops support for older versions of browser
19.0-2.0.0 - Adds new theme
20.0-2.0.0 - Updates themes to have new color & a bug fix in the firefox popup window
20.1-2.0.1
I think your original intent was to better keep track of how the plugin itself was changing, and that was getting lost with theme updates (because I have a problem and cannot stop adding themes).
Sounds good
This issue will be left open until versioning guidelines have been followed.
Following back up, so I tried to adhere to this versioning scheme for all the plugins, but apparently some platforms restrict versioning formats, such as npm packages, vscode, visual studio, and apparently also firefox addons. Which is lame, but I'm going to keep the original version scheme
THEME_MAJOR.THEME_MINOR-MAJOR.MINOR.PATCH
in the change logs.
@Unthrottled Why not apply the versioning scheme to GitHub only?
So the release on GitHub would say, THEME_MAJOR.THEME_MINOR-MAJOR.MINOR.PATCH.
But the version for the apps would be THEME_MAJOR.THEME_MINOR, or MAJOR.MINOR.PATCH. (Basically, use only part of the versioning scheme).
But the version for the apps would be THEME_MAJOR.THEME_MINOR, or MAJOR.MINOR.PATCH. (Basically, use only part of the versioning scheme).
Ah yeah, I kind of dug myself into a hole there. So with VSCode, I was stuck on like v18.0.0, and I think to update I needed a bigger number. So I stuck with THEME_MAJOR.MAJOR.MINOR/PATCH. I'll see how that works out. So I just made everything start with THEME_MAJOR.
Which I guess defeats the original purpose of this proposed change 😅 (Kind of, Theme Major will change a bunch, but Major won't)