Regarding the version numbering scheme #1764
Replies: 3 comments 5 replies
-
|
Could you give an example of what exactly you mean with a "more useful numbering scheme"? Ultimately, we are releasing often in order to "keep things flowing" and to distribute the bugfixes and enhancements made during one release cycle to users. (Or at least: to give them the opportunity to upgrade to a newer version.) In that regard, we are putting quite some effort towards maintaining a changelog giving an overview over all the changes we have made within a release cycle. Now, from our side it would be easy for releases like the current one, where we are – at the time of releasing – not aware of any breaking changes introduced to the library, to make it a minor release (i.e., If a particular version of the community edition is already working for you and your team, I'd recommend to simply stick with that version for a given project – but if you upgrade and something is broken that isn't mentioned in a "Breaking Changes" section in our changelog, please definitely do file a bug report: chances that we don't discover it on our own are, unfortunately, pretty large. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it's fair to say that our numbering scheme is time based. Our release schedule is time based, but our versioning is not. Aside from keeping development pumping along, since we're still at a somewhat unstable point in the project, time based releases are the best way to conveniently allow people to experience the newest improvements in a timely, stable manner. To the best that I can tell and from what I vaguely remembering being decided before, we're loosely following semantic versioning. This is a pretty good argument against SemVer in my opinion. I really agree with what he said here:
Now, I actually think we're following this ideal of major, minor, and patch pretty well. We have not reached a point where we have a major release -- we still have some big milestones ahead of a major release that we would like to tackle. We also aren't churning out patch releases (v0.1.1 was kind of an anomaly since we were still early in the project and figuring out how we would release versions). So I think we're well within releasing these, more or less, as minor releases. I could see here an argument for nightly releases or a If we started releasing our monthly releases as patch releases (like
While this can be true (and probably is more true of this last release with people being busy), I would argue that our monthly releases are, more or less, pretty consistent with each other. I think they belong as minor releases for now, and I think they generally consistently come with a lot of enhancements, bugfixes, and new features.
As behackl said, read the changelog! It's there for your benefit so that you can discern for yourself whether or not you should/need to upgrade as well as to see what's changed. Just because there is a new release does not mean you must upgrade, and if you're in the middle of a project, I would never upgrade unless I absolutely need something from the new release. If you do find yourself needing something, check the PR mentioned in the changelog for that change and see if it's a change that you can easily replicate yourself locally. Sometimes replicating a change to fix a bug or add a feature is better than upgrading -- particularly if you're in the middle of development. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps at some point we should look into some sort of nighty(/weekly/other time period?) releases that can be installed with pip from GitHub or something of this sort. Though I imagine our actual versioning scheme won't change much from this. It would be more to give people the latest changes easily and would be a bit more conducive imo to developing for longer periods than a month to focus on big features, reworks, and more major release type material. |
Beta Was this translation helpful? Give feedback.
-
|
You can always install the main branch using |
Beta Was this translation helpful? Give feedback.
-
|
You can and I was thinking of something similar where we have a script autogenerate GitHub releases nightly (or some fixed period of time). The benefit to this instead of installing main is that it gives a better point of reference to anyone trying to help someone who installed a nightly build. |
Beta Was this translation helpful? Give feedback.
-
|
Is there another library that does something similar? |
Beta Was this translation helpful? Give feedback.
-
|
Nightly releases aren't uncommon. For example, Mozilla uses them as well. Here's an example https://ftp.mozilla.org/pub/firefox/nightly/ |
Beta Was this translation helpful? Give feedback.
-
|
Moved this to a discussion as it seemed more appropriate. Pinging @dabnciencias @WampyCakes @behackl in case you didn't get a notif for it. |
Beta Was this translation helpful? Give feedback.
-
I understand a decision has been made to release a new ManimCommunity version each month to keep everyone participating in its development motivated, which seems great. However, the current numbering scheme being time based is unideal, since the quantity and quality of improvements made in a month's time can vary quite arbitrarily. Therefore, I'd suggest changing to a more useful numbering scheme, which is more indicative of both the amount and depth of the changes made in each release. This could help people currently doing animation projects in manim to have a rough idea of the changes made and whether or not to consider upgrading to the latest version, and not feel 'lost' regarding the newest version with each coming month -as has personallly happened to me and the team I work with.
Beta Was this translation helpful? Give feedback.
All reactions