Handling libraries with multiple version branches

[martinklepsch]

Basic question: some libs maintain more than one version branches (i.e. jQuery v1 & v2). How do we handle these in CLJSJS?

@crisptrutski (from #112):

---

Good question about the dual branches - I'd hazard that yes it would be worthwhile.

It may be worth considering how CLJSJS handles multiple long term versions - perhaps it's worth keeping the heads of both as separate folders (or build tasks), so that they can be bumped independently.

Another example, although not that relevant to the Hoplon/React wielders downstream of CLJSJS, would be Angular. Both v1 and v2 there will be under development for years yet it seems.

Don't see any issue publishing to the same clojars resource, but having to zigzag back to say provide jQuery 1.12.0 would be awkward.

While these are fringe cases, and also there's a high correlation between Clojurescript apps and bleeding-edge-everything, to me the cost of a separate folder or task (package.v1) is so small that handling the fringes more elegantly is worth it.

---

[martinklepsch]

perhaps it's worth keeping the heads of both as separate folders (or build tasks), so that they can be bumped independently.

Sounds like a good idea. Probably this can be easily done by just providing two different build task for the different branches.

Don't see any issue publishing to the same clojars resource, but having to zigzag back to say provide jQuery 1.12.0 would be awkward.

"Zigzag back" as in having different branches? Agree about pushing to the same clojars resource.

While these are fringe cases, and also there's a high correlation between Clojurescript apps and bleeding-edge-everything, to me the cost of a separate folder or task (package.v1) is so small that handling the fringes more elegantly is worth it.

Most of the build tasks are so similar that much of the information can probably provided in a simple datastructure like this.

{:v1.11.2 {:min "http://..." :dev "http://..." :min-sha "xxx" :dev-sha "xxx"}}

The package task could then just take a :version argument and if it's omitted take latest. Only problem then would be that extern files are versioned through git.

[crisptrutski]

By zig-zagging, just meant having alternating [jquery] upgrade to 1.x.y and [jquery] upgrade to 2.x.y commits in master history for cljsjs/packages. A small thing, but looks like a mistake when an "upgrade" goes in reverse.

Handling different externs - it's that just a matter of storing outside the classpath and using sift to move them in?

Going the data-driven approach makes sense, especially for making new libraries easier for new-comers to add. Including the precise version in the map is a bit confusing to me though - are you then wanting to treat that map as append only, and old versions would be retained?

Here's a related suggestion, breaking things in half:

1. A generic data driven task for "trivial" cases, that takes [:min :min-sha :dev :dev-sha :externs], where :externs is an optional path to externs outside of classpath (or a URL).
2. A data driven approach for having multiple version outputs from a given build.boot file: {:v1 {:version "1.9.1-0", :task 'package-1, :task-options {:min ..., :min-sha ...}}, ...}

Then for boot composability, the downstream tasks could be called with each task's outputs and the appropriate versions set.

This would be a waste of cycles and bandwidth to build versions that haven't changed, or to check and upload only packages that aren't already on Clojars, but would save manually running the boot task with the version that changed.

By the way, do you build and publish all additions to this repo manually?

[martinklepsch]

Including the precise version in the map is a bit confusing to me though - are you then wanting to treat that map as append only, and old versions would be retained?

Basically that was the idea. I see though that this might end up in pretty long lists after some time so probably not the best idea.

By the way, do you build and publish all additions to this repo manually?

Currently I merge changes, verify that stuff looks ok (boot package) and then publish (boot package build-jar push-release).

[martinklepsch]

@cljsjs/contributors Anyone opinions or suggestions?

Maybe the easiest solution for now would be to provide package-v1 and package-v2 tasks in packages that need to maintain multiple branches.

[crisptrutski]

@martinklepsch Took a quick swing at basic stand alone tasks. Code sharing is a bit clumsy, but gets the job done.

[Deraen]

Multiple package tasks might make sense if the externs are pretty much shared. If not, it would probably be easiest to just have multiple folders for different versions. They can still use same artifactId.

[crisptrutski]

Separate folders does seem easiest. So easy to dream up unnecessary complexity..