Less.js: Can we still maintain a 2.x branch?

[Justineo]

2 → 3 introduced breaking changes and some people may still have to stuck with 2.x for some time. Can we still maintain a 2.x branch and release more 2.x versions to fix security vulnerabilities inside dependencies (by just updating package.json)? eg. 2.7.3 had fixed the version of request to 2.81.0 which depend on a risky [email protected]. We may just need to update request to 2.82.0.

[seven-phases-max]

You can always create a fork I suppose. This is how the things are supposed to work in a perfect open-source minded world (fork fork fork) - strange they never do in the reality :).

[Justineo]

It's actually not so. There are tons of projects depending on less itself. A fork doesn't automatically change those references. I don't want to keep telling those 2.x users "hey switch to my fork because Less is not maintaining 2.x anymore". This involves a lot, there are very deep dependency chain there in modern JavaScript projects. A full "open-source minded" is not equal to ignoring the reality.

[Justineo]

In case I got you wrong, I'm willing to help if the suggestion is acceptable and owners are to help updating npm packages, not to tell me to publish my own less package.

[seven-phases-max]

You are ignoring the fact that there's nearly zero efforts in shallow copying such fork back here and then releasing it under "the official" credential (so user don't even notice anything).

But, you know... I just suspect that in:

Can we still maintain...

... by we you mean ... who exactly? And when things will go wrong and users come here complaining about issues who would be "responsible for response"? Maintenance is the main problem (obviously changing one or two characters in package.json is not).

I don't want to keep telling those 2.x users "hey switch to my fork because Less is not maintaining 2.x anymore".

Neither I see any problem with this. If they do care then they'll switch. If they don't then it's EPTH. "Reality" does not mean putting all burden on developers.

[Justineo]

You are ignoring the fact that there's nearly zero efforts in shallow copying such fork back here and then releasing it under "the official" credential (so user don't even notice anything).

No. Of course I'm aware of modification is dead simple in this case. The key point is that whether we can continue to publish to npm in the name of less itself. I cannot do it myself so I have to ask in advance to make sure the owners have the intention to do this.

... by we you mean ... who exactly?

I deliberately used "we", just to avoid implying it's the responsibility of any specific person. "We" can be project owners, myself, or anybody in the Less community who is willing to help.

"Reality" does not mean putting all burden on developers.

Am I missing something? How does this come from? I'm not "assigning" anyone to take the responsibility. If we share common opinion on the request, we can make the project itself better, rather than splitting into different forks which confuses users. How would forking and releasing a modified version silently be better than discussing this with project owners first?

[matthew-dean]

2 → 3 introduced breaking changes and some people may still have to stuck with 2.x for some time.

Which breaking changes?

[matthew-dean]

As to the general question of doing a 2.x future release, if someone wants to maintain that, I'd have nothing against that. It's more publishing / maintenance work, so I'd love if someone wants to be added as an NPM publisher. I'm still waiting for someone else to take on that role.

[matz3]

We are having the same issue, but with v1.

We are (unfortunately) still using v1.6.3 which has a (potential) security vulnerability, which is now showing up quite prominent with the new npm client (see npm audit).
An upgrade to v3 isn't possible right now as we have several projects relying on that old version and it won't be that easy to migrate, so this will take us quite some time. I think even upgrading to v1.7.5 (which anyway has the same vulnerability) isn't that easy.

Also here, an update within the package.json would be sufficient:
"mime": "1.2.x" => "mime": "^1.4.1"

See https://github.com/SAP/less-openui5/issues/25

[matthew-dean]

@matz3 There haven't been that many backwards-incompatible changes over the years. Have you tried upgrading?

[matthew-dean]

Less doesn't really have enough maintainers at the moment to properly maintain a current release, let alone two separate major releases, so I think this issue should be closed as something we can't really do without more contributors.

[matthew-dean]

Closing as won't fix.