Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Should we use Semantic Versioning in release numbers #3709
so, do we need to switch to that version format ?
Inconveniences and nuances:
Maintainers team is tiny. Non of maintainers focused on project full hours and do progress base on their free time. So big updates are impossible to accomplish in one release. There are many occasional contributors that provide fixes to bugs. All this contributors need is to pass acceptance of fix and start to use result as soon as possible (the only incentive to contribute). So delay in release will discourage contributors - not acceptable. I selected 1 month period , only because release process is time consuming and I do not want to spend my time on releases only. This period is easy to remember for me.
Checkstyle has api package for projects that want to embed it (plugins, ....). Checkstyle exposing configuration file there all properties and modules are mentioned. We have huge problems in API classes and maintaining badly designed modules and their properties.
it is partly semantic.
I think this is a good idea, it makes it clear when releases break backwards compatibility.
Indeed we need to make sure we adhere to the standard strictly and not introduce backwards incompatible changes in minor releases, only in major ones, else the benefit of semantic versioning is lost. According to the SemVer standard this does not however apply to non-public APIs I believe, these can be changed every minor (or even patch) release and should be marked as such.
If we are going to follow the format then it seems to me we need to follow what the numbers mean, otherwise I would rather stick to our current model, even if it isn't standard.
So the question becomes: Are we going to change how we release major/minor/patch changes and how are we going to do that?
We have a number of checkstyle 8 breaking changes, I assume all of them have to be released in 8.0.0 before we can go to 8.X.Y, otherwise the next version should become 9.0.0, right? This would require to have people actually work on them, instead users picking and choosing fixes they would like to work on. That in turn requires us to better plan our issue schedule, which would require us to go back and remark all current issues with more depth. If we don't have many users working on issues, especially ones they aren't familiar with, release schedule might not be able to maintain one month release.
If we truly follow the versioning, we won't always have a
I am afraid to run major version to quickly. May be after stabilizing API and problematic design of existing modules we could switch to that model.
We will never release all that changes in one release. That is why I am kind of against blind following of semantic version model - it does not work well for time-based releases with non completely focused team for whole day.
there are almost no maintainers, so forcing people does not work. As we can not afford planned work, we use "controlled bazar" and do some progress.
I never succeeded in this, I doubt it is possible in our model of work. Time of maintainers is contributors is too unpredictable. Issues that bother them first should be done first to give them intensive to contribute. Maintainers could use planned focus, but we need more members to make it work.
yes, that is why time based release period (1 month) was selected by me a while ago.
we have to, as by standard there MUST be 3 digits.
from semantic description:
What is "incompatible API changes" for you ?
We must have 3 digits, yes, but it won't always be a 0. See release 7.1.2. I was only referring to the fact its not always 0.
Any public method signature change. Modifier change (
Obviously most of this is too strict for us. We are constantly finding flaws in the logic of our own code that is years old. That is what most of checkstyle 8 labels are.
I agree. Stick to current model and switch to 3 digits and semver when we can. Doing it now would probably confuse people when we break stuff in-between major releases.
It is also not clear what is really API and what is not in checkstyle. Check classes are in a sense API (user calls them directly in config) but they don't reside in API folder.
for now we use Romantic/Sentimental versioning http://dafoster.net/articles/2015/03/14/semantic-versioning-vs-romantic-versioning/
Ones we finish removing all implementations from our API package , we can switch to semantic versioning.