search

software-development-guidelines / explicit-versioning

A versioning system for PordPress, Joomla and Drupal.
https://software-development-guidelines.github.io/Explicit-Versioning
3 stars 3 forks source link

Creation of the draft version #2

Open colomet opened 7 years ago

colomet commented 7 years ago

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

Exadra37 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

colomet commented 7 years ago

https://github.com/npm/node-semver/issues/54 @hueniverse what do you think about that version system? any idea?

Exadra37 commented 7 years ago

@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 commented 7 years ago

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.

Exadra37 commented 7 years ago

@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 commented 7 years ago

@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:

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:

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

colomet commented 7 years ago

Release.Major.Minor.Patch

Exadra37 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@colomet

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

colomet commented 7 years ago

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 commented 7 years ago

@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.

colomet commented 7 years ago

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 commented 7 years ago

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

What do you think?

colomet commented 7 years ago

Yes, simple and direct.

colomet commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

colomet commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

xBorderie commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

Exadra37 commented 7 years ago

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

sapioit commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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).