Semantic versioning requirement is nonsense

[titoBouzout]

My packages include no dependencies, the requirement for semantic versions looks like non sense to me.

You are breaking the purpose of "semantic versions" when requiring to new packages, to follow "semantic versioning" while at the same time you require ST version. Im wrong?

[titoBouzout]

Well, these are not the reasons on why semantic versioning exists. Is not to solve the thing you described. If for something else. All of my current packages, does not include any versioning system, and these are working just fine. I dont want to maintain versions, so this requirement makes non sense to me. IIRC packages based on branches, were getting the version from the commit date, which is perfect for me. and I would like to keep it that way. Is simple and goes to the point.

Semtnic versioning is for something else, go and read it http://semver.org/

[titoBouzout]

Mmh, if you don't think is a big problem, Im happy for you. I don't want to maintain versions numbers on tags for no apparent reason. To me the date is enough, which should be enough for you too to do whatever you want to do with my package. Do you understand that? Package control is capable to keep the system that originally provided and still provides. I see no problem with it. I don't want to complicate it for no gains.

You suggesting to tag the tip as 1.0.0 and push always there? So users will never received updates? that's the best thing you can come with?

[titoBouzout]

For simplicity I suggest to make semantic versioning a requirement for packages that include dependencies and allow anyone that has no problem with it to use it. For everyone else just use branches as now that is working just fine.

[FichteFoll]

Semantic versions are indeed meant to be used for dependencies primarily, since the concept of an "API" is very abstract for end-user tools or applications since it is not specified. That does not mean semver can't beused that way; you just need to use your own judgement there.

That said, semantic versions are primarily required because of the version format it enforces. That way we can be sure to only find the tags that are supposed to be found and can follow a strict and well-defined versioning scheme as opposed to having countless schemes and comparing inbetween them too.

[FichteFoll]

@wbond needs to speak about why exactly branch-based release channels are deprecated. I personally never used them even when PC couldn't parse tags (because I prefer the seemingly but not entirely arbitrary version increments instead of entirely arbitrary datetime stamps). The main disadvantage about not using tags is the inability to properly use the update messaging system.

[wbond]

Tag based releases are required because it signifies thought goes into a release. Just grabbing every commit from a repo leads to lots of broken packages as an author messes around with the code.

Obviously I can't force you to semantic versions, but I can force a particular format of version numbers. This allows features like pre-releases to be implemented, plus messaging. Eventually my hope is to allow users to pin package versions, or prompt for major version upgrades.

I have no intention of changing the format for versions, or how the default channel includes repositories. My intention is to get stricter over time.

I'm sorry if you don't like it.

[titoBouzout]

OK, thanks

[idleberg]

Allow me to add my 2 cents to an already closed issue. Personally, I prefer tagged releases for being in control of what is being published. However, I can understand laziness in general. What I prefer about Atom's way of publishing is that maintaining versions is simple: apm publish major|minor|patch.

My guess is that most users of Sublime Text will use the editor when creating their packages, so maybe a future version of Package Control could provide a similar system to push new releases – within Sublime Text itself.

Example:

• Select "Package Control: Publish new version"
• Select major, minor or patch release. Optionally, provide a custom version tag.
• Confirm "Do you really want to publish a new version?"

[wbond]

@idleberg This means building a git/hg client for Sublime Text, and dealing with all the environment junk and trying to redirect user input for authentication, etc. The Python world's package management tools wouldn't even get us this (such as how Atom rebranded npm's tools).

I'm sure someone could do this – unfortunately I don't currently have time. Open source just doesn't pay the bills. 😄

[FichteFoll]

In normal circumstances, the process is literally:

1. Find the highest versioned tag
2. Do version increase as desired (major, minor, patch; set smaller to 0)
3. git tag v<the-version> & git push origin v<the-version>

This could be done by a really small python script, for the regular case. But since we know the regular case will more often than enough not be the case, things start to get really messy and supporting this will become a mess. Compared to what goes into the release (i.e. the code, potential update messages, documentation), the amount of work that goes into releasing a properly versioned package that can communicate differences in code to its users is absolutely negligible.

For apm this works because, as @wbond said, they basically rebranded npm and set that on top of git (and github). So in most circumstances you'll have a predictable environment since the user is supposed to use your tool apm for the entire process. I don't see this going anywhere in the Sublime Text world, or rather coming from.