exadra37-versioning/explicit-versioning

Optional Identifiers

Exadra37 opened this issue · 10 comments

Exadra37 commented

After the Explicit Version schema we may want to use optional identifiers, like:

  • 1.0.0.0-Alpha1
  • 1.0.0.0-Beta1
  • 1.0.0.0-RC1
  • 1.0.0.0-Build123

And any other one we may need for our internal or public Software Release process.

This optional identifiers MUST NOT clash with the Explicit Versioning Specification Schema intentions:

For example not using an Optional Identifier to say that:

  • Major Relase.
  • Breaking change release.
  • Compatible Release.
  • Fix Release.

A section in the Specification must be added to clarify this Optional Identifiers usage.

This is related with the Pull Request comment #2 (comment)

corysimmons commented

I'm saying, why can't the -Foo BE the "Major Release"?

Exadra37 commented

The Major Release is always the first number from the left side... From 2.3.5.1 the Major Release you refer is 2.

Anything else after 4th digit must be followed by a dash - and be used as an Optional Identifier as per described on this issue topic.

corysimmons commented

Right, but why?

What's the purpose of the major release? Just a marketing tool? Then why not just append a -v3 to the end (so it's backwards compatible with npmjs.com, rubygems, etc. etc. etc.)?

colomet commented

@corysimmons the difference is not a backwards incompatible are Public API related. We need to split that. Also major UX Design changes or ending of support or ...

Exadra37 commented

@corysimmons

The point of Explicit Versioning is to define a explicit schema for the life cycle of the Software.

Therefore using an Optional Identifier to mark the release that declares that the Software have suffered deep changes is defeating the purpose for what this specification have been created.

More details on the reason this specification have been created can be found here.

sapioit commented

Also, if SemVer and ExplicitVersioning are syntax-compatible, it will be more difficult for the people to differentiate between the versioning that is used. Using 4 digits, one can tell at a glance whether SemVer or Explicit Versioning is used, without the need to check the (available/public) documentation, which might not even cover that.

sapioit commented

Maybe also add 1.0.3.54-User-3653 for the case when more people have to use the same branch... just to be there, as an example...

Exadra37 commented

@sapioit

I complete disagree with tagging for a specific user, that is a use case for branches.

The workflow goes like:

  • Projected created with a branch name matching the Project name.
  • Milestones for the project are created with respective branches matching the name of each Milestone.
  • When the Project only have 1 Milestone, no need to create a Branch for the Milestone.
  • Each card in the Milestone represents only 1 issue with 1 task.
  • When the Developers starts the tasks it creates a branch like issue_number-issue_description... eg 1-add-login.
  • On task/issue completion a Pull Request is done from the issue branch to the Milestone branch and after merge the Milestone branch should be immediately merged into the Project branch.

So Issues branches are owned by only 1 Developer and Project and Milestone branches are owned only by the Admin and Developers can't push to them, they only can make Pull Requests.

The real workflow is even more detailed, but I tried to keep it as much simple as possible.

  • ❤️1
sapioit commented

While I am 100% for that, don't forget that there's a lot of people out there, and not all of them are working in proper development conditions...

Exadra37 commented

@sapioit

I know that lot's of people are not working in proper development conditions... I was there not too much time ago ;)

This means they need to take the next step and improve their knowledge, workflow and embrace the Best Practices and Tools to get their work done.

We Developers that are already one step ahead should mentor the ones that are some steps behind :)

I changed completely how I develop and organize my workflow after I decided to invest time in my own formation and improvement as Developer.

I recommend in this Order:

The programming language used in the book doesn't matter, the Developer learning this must concentrate in the concepts and best practices that are universal.

If a Developer takes the time to read the books watch de videos and do some code in is language of preference to practise what is learning I can guarantee that by the end a new Developer as born ;)

But the Learning curve doesn't stop here, the above are just laying the foundations for a good Developer.

  • ❤️1