Hello,
Tracks are meant to separate incompatible versions. If, as you say, 1.6 is compatible with 1.5 and older, then it seems to me you don’t need a track, right?
To put it another way, once 1.6 is out, why would anyone need to install 1.5, if 1.6 will run their code without changes? Further, if 1.6 is out and I get auto-upgraded from 1.5 to 1.6, nothing would break or change from my point of view, correct?
The way you describe it, that eventual hypothetical 2.0-ish release would perhaps need a track (after 1.7 and 1.8 which per what you described would also run all 1.x code correctly and there would be no reason for someone who was running 1.5 to not upgrade automatically to 1.6, 1.7 or 1.8); once 2.0 is out, you would pubish it in latest, which would upgrade everyone (at this point you’d have to put the last 1.x release in, say, a 1.8 track for people who want to stay in the 1.x series, and publicize it so people who choose to stay behind can switch tracks before 2.0 is released).
In general I’m +1 to creating the track you request if you feel it’s necessary, but I wonder if you could read the above and think whether it holds true; if you can think of a reason to separate 1.5 from 1.6 and so on, I think it would be valid to do this with a track.
That said - The 7-day comment period has elapsed and we only have a +1 (contingent to you reading the above and confirming you do want a track) - so I’ll poke our friendly @reviewers for more votes and extend this voting for 3 more days (per Process for aliases, auto-connections and tracks). We’ll check again on Monday!
- Daniel