Creation of the draft version

[colomet]

Reviewing the content from: @sapioit Release.Breaking.Feature.Fix & @Exadra37 Semantic Versioning - Semantic Versioning with 4 digits

[Exadra37]

@colomet sorry but I don't agree with you 4 digits schema.

In my opinion is not addressing the problem as it should and also not very clear.

My specification is simple, short, easy to understand and is not targeting any specific software type.

After read the article of @sapioit I am thinking in renaming it from SemanticVersioning to ExplicitVersioning or maybe StrictVersioning and I hate abbreviations because they are implicit.

[colomet]

I´m targeting my own problem. To work with wordpress as a CMS where we do create plugins and themes integrated with other plugins and themes.

I think is it pretty simmilar to yours. What is the problem I´m not addressing? and why is not very clear?

thanks

[Exadra37]

Sorry I was not clear enough...

Then names you give to the Schema RELEASE.ENHANCED.FEATURE.PATCH do not match the breakdown of them, that are in the order RELEASE.FEATURE.ENHANCED.PATCH.

Also calling FEATURE to breaking changes does no make sense to me.

I don't see why my approach doesn't work for Wordpress, etc.

I also work with Prestashop and use my Semantic Versioning without any issue.

I may rename it so that becomes more readable in all scopes, like MAJOR_RELEASE.BACKWARDS_INCOMPATIBLE.CODE_IMPROVMENT.CODE_FIXES.

[colomet]

Just thinking. What about Release.Major.Minor.Patch.

I don´t like to have warming names because I think a breaking is too complicate to predict.

If I have a theme and some one make a plugin for a theme, Maybe there is a problem we can not predict and we break the site just creating a new feature. And that breaking just happen to one guy in some place, not all the other ecosistem of plugins. We can not to know if we break or not all the time.
Maybe is a situation with wordpress and we did nothing wrong but the situation is wrong.

Everything could be a breaking and nothing. That´s why I avoid to use such names. I would like something more general.

[colomet]

@xBorderie i read your article and I would like to ask your opinion.
thanks

[colomet]

npm/node-semver#54 @hueniverse what do you think about that version system? any idea?

[Exadra37]

@colomet if you read why I created my specification is because I really want to have an explicit digit that announce backward incompatible changes.

Release code that can break without being announced as a breaking change means that we don't have a good suite of tests in our code.

With a good suite of tests the chances of that happening are greatly reduced and when happens we just need to add one more test to the suite to make sure that will not happen again in that scenario ;).

[sapioit]

Why not Release.Incompatible.Compatible.Fix (or Patch instead of Fix)?
That is, in order to make it as universal as possible without making it interpretable.

• Release has to do with major releases, which usually mean the end of support or a new recommended version
• Incompatible says that this update breaks compatibility with previous versions
• Compatible says that this does not break compatibility with previous version
• Fix/Patch says that this fixes something that is not working as intended

[Exadra37]

@sapioit sounds better your proposal while keeping the meaning and making it universal at same time.

That one I don't mind to use in my specification and at same time changing the name of the specification to ExplicitVersioning or StrictVersioning.

[colomet]

@Exadra37 I understand your point.

And I think we have an agrement of the definition in each one of the 4 components. As @sapioit just write:

• A: has to do with major releases, which usually mean the end of support or a new recommended version
• B: says that this update breaks compatibility with previous versions
• C says that this does not break compatibility with previous version
• D: says that this fixes something that is not working as intended

What is missing is a appropiate name. Don´t you think?

I would like to extend the @sapioit definition a litle more, if you allow me:

• A: has to do with major releases, which usually mean the end of support or a new recommended version (I will extend with Api breaks or full new UX design)
• B: says that this update breaks compatibility with previous versions (big UX design changes)
• C says that this does not break compatibility with previous version
• D: says that this fixes something that is not working as intended.

About the names. What about:
Major.Jump.Minor.Patch

[colomet]

Release.Major.Minor.Patch

[Exadra37]

@colomet

The definition I use in my specification still valid for each Release.Incompatible.Compatible.Fix but can be improved to mention the Ux bits.

[colomet]

@Exadra37 I don´t would like to use any type of name like incompatible or compatible or break because somebody could believe if is not a braking change, that means it is safe to update. Maybe is not a breaking change with the addons related to the plugin but maybe with other plugins in the installation.

[Exadra37]

@colomet

Your proposal just hides the problem... How can your proposal tell that is safe to upgrade?

[colomet]

I can´t, you never can tell is safe to upgrade. Just is safe with the FIX (we can assume that the 99.999 of the situations).

That´s why to tell one upgrade is a breaking and the other no, could make a bad idea of the reality.

[colomet]

@Exadra37 that is a modification of your especifications.

Given a version number A.B.C.D, increment the:

1. A version when you make incompatible API changes,
2. B version when you add functionality in a backwards-incompatible manner,
3. C version when you add functionality in a backwards-compatible manner, and
4. D version when you make backwards-compatible bug fixes.

Additional labels for pre-release, release candidate and build metadata are available as extensions to the RELEASE.MAJOR.MINOR.PATCH format.

---

• A:
  • Major Code Overhaul that impacts a significant number of end points in the Public Api will increment version to 2.0.0.0.
  • Major UX change that impacts in a significant way the usability will increment version to 2.0.0.0.
• B:
  • Any Breaking Code Change will increment version to 1.1.0.0.
  • UX change that impacts the usability will increment version to 1.1.0.0.
• C:
  • New Features will increment version to 1.0.1.0.
  • Refracting Code that do not impact Public Api will increment version to 1.0.1.0.
  • Deprecating Code that do not impact Public Api will increment version to 1.0.1.0.
  • Removing Code that do not impact Public Api will increment version to 1.0.1.0.
• D:
  • Security Fix(es) will increment version to 1.0.0.1.
  • Bug Fix(es) will increment version to 1.0.0.1.

[colomet]

But I don´t understand if to write about the public API in C, if in C and B, or if just in B.

[sapioit]

Let me try to make it more... compact, concrete and maintaining universability.

• Release is incremented when changing the API, changing the UX, switching to a new recommended version or ending support for previous versions
• Incomaptible is incremented when changing the UX and when breaking compatibility with previous versions
• Compatible is incremented when changing, adding or removing code while remaining compatible with previous versions
• Fix is incremented when a bug is fixed, or a security gap is solved

What do you think?

[colomet]

Yes, simple and direct.

[colomet]

I think we could try to use more close sentence between Incompatibe and compatible. maybe:

Release is incremented when changing the API, changing the UX, switching to a new recommended version or ending support for previous versions,
Incompatible is incremented when adding, changing or removing code while breaking compatibility with previous versions or changing the UX,
Compatible is incremented when adding, changing or removing code while remaining compatible with previous versions,
Fix is incremented when a bug is fixed, or a security gap is solved.

[sapioit]

And I am pro using the whole words, instead of a conmpact form. Heck, we're telling the other programmers to use variable names that are explicit, but don't do it ourselves?

#ExplicitVersioning

I tweeted this with the previous hashtag...

[Exadra37]

Once my specification already matches the Explicit Versioning and was the base for this discussion, plus I have already said before I am willing to adopt the naming @sapioit have suggested to the schema, in my opinion would make more sense to continue from my repository.

[sapioit]

Sure, just tag me (and maybe @colomet if you want to or he is okay with it) on your repository. I forgot the link and can't find on your profile (for some reason).

[Exadra37]

The link is this one https://github.com/exadra37-versioning/explicit-versioning

[colomet]

My idea is to create a place for documentation. To create a changelog, a readme file and other documents and to have it all of them uder the same github organization. What if we do create a new organization and inside we start to create the repository related to documentation where other people could join us?

what about the organization name : Software Development Guidelines ?

[colomet]

I could always to use a fork inside of that organization.

But for me, the problem of the names of the components remain.. Incompatible and compatible... are a not apropiate name

[colomet]

I know you don´t like the short names, but Software Development Guidelines is too long, maybe is better SoDeGui

[xBorderie]

Hello, and thank you for asking for my input.
The thing, I am unsure the PrestaShop versioning is relevant in a "let's improve SemVer" conversation.

PrestaShop's 4-digit version, for all intents and purposes, uses SemVer, only in a way that will not scare users away: moving from 1.6.1.0 to 2.0 would have been the thing to do SemVer-wise, but to us such a move would only have been warranted by a huge code rewrite. For that reason, it was chosen to keep the first two digits as the "majorness" indicators, thus moving to 1.7.0.0, the next one being 1.8.0.0, maybe someday 1.10.00, and once we get to that full rewrite, yup, sure, 2.0.0 (probably abandoning the fourth digit on that occasion).

Hence, I'd agree that having a non-semantic 4th digit, equivalent to version names, would be an interesting idea instead of having to jump to the next major at the first sight of a breaking change -- but that also forces us to better think when breaking things.

[sapioit]

@colomet What about Development Craftsmanship?
@xBorderie Firefox used a four digit versioning since the version 1.5, but I don't know if they used a similar type of versioning, but it seems the first digit started being updated in a support-dropping and it looks like an example of how SemVer can mess up a product's version numbers.
I mean, they reached Version 60 in only a few years. Think about Firefox about 2 decades. Version 1326?

[Exadra37]

@sapioit something like https://php-scribes.com ?

[Exadra37]

@colomet this may be the specification you want to adopt http://blog.legacyteam.info/2015/12/romver-romantic-versioning/

[sapioit]

@Exadra37 EXACTLY !!!
But they still try too hard with the semantics... they should throw an "Explicit" here and there...
After all, we're not only trying to change the versioning numbers, but also the mentality of the developers.

[Exadra37]

@sapioit

Php Scribes is an idea of mine and Semantics is used in the sense Software should be easy to read, but after all this discussions I may rephrase it to Explicit ;)

[sapioit]

Not entirely. After all, semantics are needed to understand how to read and write software, but writing explicit code (that leaves no room for interpretation) is one of the best practices (except when the end-goal is to write code as efficient as possible).