I’d like to request the creation of two tracks for the dmd snap package:
2.074
2.075
These correspond to the current and upcoming minor release versions of the package.
Hello Joseph!
The process outlined here applies to track requests as well, (see the first post only). This allows reviewers and architects to chime in on the request.
Per that process, could you please provide the store URLs or mention the publisher and snap name for your snap if it already exists? (if not, just mention it; I think the requirement should not be mandatory for tracks since the snaps may not have been pushed yet).
Also, because this is likely to come up: could you explain the need for tracks for those two very similar-looking versions? Remember - tracks are meant to allow users to receive updates to an earlier release of the software, on which they need to stay because of data incompatibility or other reasons. With DMD I have two questions on this regard:
-
I notice DMD does point releases (2.074.1 and so on) even while a newer release is already out, which would seem to match the use case for tracks. But these point releases come very close to each other, which means tracks would need to be requested and created very frequently.
-
Also since DMD seems to be a compiler, I wonder how necessary a track would be: do people using 2.074 really need to stay on that version or can they go to 2.075 without needing to rewrite their code? Is there a runtime that would render code unrunnable if dmd itself is upgraded? Tracks enable people to stay on versions for which an upgrade would be cumbersome, like needing to update a lot of data, so I’d be interested to know if that’s the case here.
@roadmr ah, it seems like the track request process has got more formal since the last time I had to request any 
Per that process, could you please provide the store URLs or mention the publisher and snap name for your snap if it already exists?
Snap: dmd. Publisher: dlang.
Could you explain the need for tracks for those two very similar-looking versions?
In a similar manner to the Go snap, I’m planning on having one track per minor release of the dmd compiler (as is already done for the ldc2 snap I referred to in a different post).
The reason for two tracks is that 2.074 should provide long-term support for the 2.074.x dmd release series (first released 10 April 2017, which the current snap is built from) and the upcoming 2.075.x release series (which should come out shortly, probably in early August).
If you go through the release history here: https://github.com/dlang/dmd/releases you should be able to see that there’s a time period of about 3 months between minor releases of dmd (i.e. 2.071.0, 2.072.0, 2.073.0, 2.074.0, etc.).
The fact that there is an upcoming new minor release (2.075.0) is what motivates the request for tracks, since up until now there was no need to support any earlier versions.
I wonder how necessary a track would be: do people using 2.074 really need to stay on that version or can they go to 2.075 without needing to rewrite their code?
Generally speaking where DMD is concerned, one can’t exclude breaking changes between releases. So there are definitely use-cases for staying on an earlier version.
Does that give you everything you need?
Thanks & best wishes,
-- Joe+1, basing off of previous cases like this.
Hi Joseph,
The tracks have been created as requested. Enjoy!