Collect backward incompatible changes in 1.4.0 and decide which way to go

[SomMeri]

Hint:

• Cannot compile nested multiple variables with latest 1_4_0 less/less.js#1042 (comment)

[alexo]

May I suggest a versioning strategy which would reflect the less.js version? More specifically, the features from 1.3.x of less.js should be released as part of 1.3.x version of less4j, similar strategy can be applied to 1.4.0.

The idea is to be able to keep separate (backward incompatible) versions of less.js and allow users of less4j to choose which version they want to support.

[SomMeri]

Hmm, I through about having one less4j and a switch/configuration option that would turn on and off old/new syntax. It is possible that less.js will have such option too, they discussed it in their issue database. They did not made final decision yet (I think). If they will merge 1.4 back to main and have it configurable, I guess we should too.

The other question of course is, whether less4j going to be able to support two versions at less.js pace and if not, which one should be priority.

[alexo]

Adding configuration option, sounds like a good solution too.. I'm wondering how hard it is from less4j perspective to keep various versions in the same code base...

I think it worth analyzing both approaches and check which one is easier to maintain:

• Each version of less should have associated dependency (jar). It is very unlikely that a project will ever want to use both version of less in the same time.
• Add configuration option instructing the less version to be used.

Lets see what are the pros and cons of each option or if there are more options available before making a final decision.

[SomMeri]

I agree that the decision should not be hurried. I also think that it would pay off to watch what less.js will do, especially since they did not yet decided how exactly should new features work.

The difficulty of keeping two versions depends on how much those versions will differ. But, keeping them together should not be more difficult then having them in two branches.

• At worst, we would have to have two separate grammars and compilers - then we have to maintain them both whether they are in two branches or not.
• At best, we would have one grammar and one compiler with configurable features - this would become difficult to maintain if the grammars would move in too separate ways. We would have to refactor and split it then (whether we split them into two branches or only within packages structure does not matter much).

If we split it into two branches, then both branch name and artifactId must clearly say which less language version is implemented in that branch.

We can also have a look at other compilers (for other languages). Java uses configuration options, python has two different compilers (e.g. branches). I'm not sure what the rest of the word does and whether there is a "standard" solution.

[SomMeri]

Started wiki page to collect backward incompatible changes: https://github.com/SomMeri/less4j/wiki/Backward-Incompatible-Changes-in-less.js-1.4.0

Wiki will be more practical for list keeping and will not cross link Github issues.

[SomMeri]

@alexo "Could you keep support for less.js-1.3.x in a separate branch of less4j?"

Yes, I could.

"Also, it would be great if the major version of less4j would change for less-1.4.x."

I'm thinking about the same. I'm also thinking about making 1.4.x a priority. Less.js is going to move that way, so we should too.

"It would help if the versioning strategy would reflect supported less version."

Yes, I agree. Supported less version should be immediately clear from branch name.

[SomMeri]

I vent through all open issues labeling them as:

• Non Language Feature,
• Technical Debt/Enhancement
• Less-1.3.3 Compatible,
• Less-1.4.0 Only,
• Waiting for Less.js Implementation.

The idea is that all Less-1.3.3 Compatible should be treated as priority before branching (none of them is going to be deprecated in 1.4.0).

@alexo I think that major version can be raised when the most important Less-1.3.3 Compatible are done and the project is branched. Then the 1.3.3 language version can be raised to major and 1.4 not. The two branches would then move independently of each other.

• minor release 0.0.13: https://github.com/SomMeri/less4j/issues?milestone=12&page=1&state=open
• minor release 0.0.14: https://github.com/SomMeri/less4j/issues?milestone=13&page=1&state=open
• review documentation etc, fix new bugs if found
• branch and raise major number on 1.3.3 branch
• focus on bug fixing on 1.3.3 and start to do stuff labeled Less-1.4.0 Only.

List of issues labeled Less-1.3.3 Compatible https://github.com/SomMeri/less4j/issues?labels=Less+1.3.3+Compatible&milestone=none&page=1&state=open that are going to be open by the time major release is out.

Note: if it turns out that either 0.0.13 or 0.0.14 takes too long, I would move some issues into 0.0.15, 0.0.16, ... etc. The idea is to have all those issues done by the time major version is released.

What do you think?

[alexo]

I don't mind to postpone the major release until all issues are solved. On the other hand, I don't think release 1.0.0 has to be perfect. For me, 1.0.0 milestone is a good sign for adoption, which for most of the people means that it compiles flawlessly bootstrap twitter.

I'm wondering what is the best versioning strategy for less4j to indicate the less-1.3.x vs less.1.4.x compatibility. As long as there is no official language specification, it is very likely that people might become confused when associating a less4j release version with the less.js one. This is something worth think better about.

Thanks,
Alex

[mwanji]

I'm wondering what is the best versioning strategy for less4j to indicate
the less-1.3.x vs less.1.4.x compatibility.

If less4j is strongly tracking less.js, the easiest solution is to have
less4j match the version number of less.js. Any less4j-specific releases
could have a number behind a dash. Eg. 1.3.3 and then 1.3.3-1, 1.3.3-2, etc.

[alexo]

Though less4j aims to strongly track the less.js, I doubt it will be identical.
The problem is the lack of less language specification. Less.js is just an implementation of "de facto" standard.

[SomMeri]

@alexo It is true that keeping it pre-major release makes no sense. Less.js 1.4.0 has not been released yet and they have long release cycle, so it may take time until it is out. 0.0.13 will be out shortly (it is waiting for maven sync now). I think that 0.0.14 should not take too much time.

If nothing important comes up, I can raise major version after 0.0.14 (before branch). I want at least analyze those mixins and namespaces naming issues so I know what needs to be done. I think that major release should be in well defined state e.g., we clearly know what it missing and why.

[alexo]

@SomMeri the reason why I think that less4j deserves major version release, is because the 0.0.9 is already being used in production environment without any major issues... 0.0.13 is even more stable and better :)
Thanks for this new great release!

[SomMeri]

Less.js made tag for 1.3.3 and moved 1.4 branch into the master. They also claimed that they will not continue 1.3.x unless something very important comes up. All in all, they seem to see 1.4 as future and 1.3.x as old.

@mwanji I like the idea of language version in name, but I do not think I can hunt exact match for each less.js release. So, what about this:

• less language 1.4 and higher: less4j-0.0.15 e.g. everything the same way as up to now.
• less language 1.3 filename: less4j-1.3.x-0.0.15 where 0.0.15 is a shortcut for less4j version

Branch name would be less4j-1.3.x. Maven artifactId would be less4j-1.3.x, unless it turns out that it must match package name exactly,can not have '-' in it or that it breaks some Sonatype rule.

@alexo What are your plans for wro4j? If you are going to support only new language version, then it should be OK. If you want to have both of them, will two less versions inside packages with the same name fight with each other?

[SomMeri]

@alexo Thanks, that is good to know. I did not know somebody has it in production, so I considered it largely untested :)

[alexo]

@SomMeri I don't think there is anybody who would use both less versions in the same time and would like to switch these during the runtime.

Versioning strategy suggestion:

less4j-1.0.x - for less.js-1.3.x compatible releases
less4j-2.0.x - for less.js-1.4.x compatible releases.

Since the differences are quite big, I don't understand why only a minor version is changed. In terms of user impact, this is a very big change.

[mwanji]

You can have dashes in the artifactId, but having a version number in there
might be confusing.

If you decide not to track less.js's version, I would sort of agree with
Alex. 0.0.14-> 0.0.15 implies only bugfixes. 1.0-> 2.0 implies breaking
changes. If the chanhes are backwards-compatible, I would increment the
middle number.

[SomMeri]

Less.js moved important backward incompatible changes into 2.0.0 version, so I will re-tag issues here and branch less4j only after they create 2.0.0.

I'm going to consider differences between 1.3.x and 1.4.x as bugs in 1.3.x and implement them into less4j master.