Switch to Semantic Versioning

[adius]

http://semver.org/

[isagalaev]

Could you explain what it means for highlight.js in particular and what the change would gain us compared to current version naming scheme?

[adius]

It would make it way less stressful to update highlight.js to the latest version as you know what to expect.
Furthermore this has become a quasi standard for versioning. …and we all love standards, don't we? =)

[srigi]

+1
I cannot install latest highlight.js by bower:

$ bower install git://github.com/isagalaev/highlight.js.git#7.3

There were errors, here's a summary of them:
- highlight.js Could not find tag satisfying: highlight.js#7.3
The tag 7.3 could not be found within the repository

Maintainers of bower wont to fix this, they're complaining that semver library is not recognizing 7.3 as valid version. They say, that is up to package maintainer to fix theirs versioning.

[plasticine]

Any word on this—I would love to be able to bower install highlight.js

[isagalaev]

Sorry, I'm a bit scarce on time lately and am slowly working through all the issues. I'm gonna look at this too when time allows.

[srigi]

I found that semantic versioning alone wont help. There is a build step necessary for library to work. bower install only download sources that need to be builded into working package. Please ship also a prebuild files in github repository.

[Sannis]

I'm not very familiar with bower and clien-side development, but why you cannot use npm to install and update highlight.js? Placing prebuilded versions for browsers/node/requirejs/broserify/bower/whatever into source repository is not a good idea.

[Sannis]

According to this issue: it looks like current versioning is very close to semver.

[adius]

Oh, I didn't know that "being close" to a standard is enough. -.-
You should reopen the issue, because it's neither fixed nor obsolete!

[Sannis]

Can you refer to semver rules that was broken in last highlight.js releases? Only that hightlight.js uses X.Y not X.Y.Z versions?

[adius]

"Only"? That's basically the main point. Did you read the semver manifestat all? ^^

[isagalaev]

Before this thread turns into a war, let me look at it later today, we'll try to work something out then.

[isagalaev]

Hello again everyone :-)

It appears that we're talking about two different things here, let me address them individually (and tl;dr is at the bottom).

bower install

Highlight.js as a library can't be installed straight from the source, it simply doesn't work without the building process. The reason for this is that we have different build targets with different ways to expose the API so we keep our code in a minimal form that is then wrapped into the target format. It's the only non-fragile way of doing it. To support bower, someone has to contribute it as a new build target and maintain it further. This can be done as a patch to the current build tool or as a separate packaging project. The former is simpler but binds it to our release schedule, the latter is more independent and thus more complicated.

Semantic versioning

The spec does make perfect sense but not enough for me to care, sorry :-). Though our process is compatible with what semver is proposing, we never distinguished between "fixing bugs" and "adding compatible functionality", as it doesn't add much value. The only thing that downstream usually cares about is whether an update is supposed to break things or not (and they still have to test it in any case).

tl;dr

• I see no reason to change version policy of the library code.
• It's a moot point anyway as the bower-specific build can use semver version format just by adding ".0" to the library version (the node.js target is doing it already)

Does that make sense?

[isagalaev]

by adding ".0" to the library version

Or more precisely, do something like:

version = version.split('.').length < 3 ? version + '.0' : version;

[adius]

…well, that's unfortunate. (Btw: Bower compatibility would be really great!)

[isagalaev]

Closing for now, as there's nothing we can do on this side of the fence. Let me reiterate that it's perfectly possible to implement whatever packaging format for highlight.js, it's just can't live at this URL by default.

[isagalaev]

@adius, @plasticine btw, looks like someone did precisely what I suggested: https://github.com/components/highlightjs. So there you have it :-).