Deprecate --nightly in favor of --release-type#251
Deprecate --nightly in favor of --release-type#251wilzbach wants to merge 3 commits intodlang:masterfrom
Conversation
|
Thanks for your pull request, @wilzbach! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
| if (!revRange.empty) | ||
| { | ||
| if (useNightlyTemplate) | ||
| w.put("$(BR)$(BIG $(RELATIVE_LINK2 bugfix-list, List of all upcoming bug fixes and enhancements.))\n\n"); |
There was a problem hiding this comment.
I doubt that anyone cared about this and this simplifies the generation.
There was a problem hiding this comment.
I don't understand how this really simplifies generation, and I think saying "list of things in $VERSION" when $VERSION hasn't been released yet is a little bit worse?
|
What's this for, _pre / _next ? |
Yep the generated changelog - see dlang/dlang.org#1821 for details. |
CyberShadow
left a comment
CyberShadow
left a comment
There was a problem hiding this comment.
I don't understand this change. Will we have so many release types that it makes sense to make it an arbitrarily specifiable unvalidated parameter and even go as far as deprecate the old way of specifying the release type?
Sorry it took me a while to look at this properly as I was rather confused about a lot of things here.
| "version", &nextVersionString, | ||
| "nightly", &useNightlyTemplate, | ||
| "nightly", &useNightlyTemplate, // deprecated, use --version=nightly | ||
| "release-type", &releaseType, // e.g. beta or nightly (stable by default) |
There was a problem hiding this comment.
Why not:
"nightly", { releaseType = "NIGHTLY_"; },
"beta", { releaseType = "BETA_"; },| else | ||
| w.formattedWrite("$(VERSION %s, =================================================,\n\n", nextVersionDate); | ||
| import std.uni : asUpperCase; | ||
| w.formattedWrite("$(%sVERSION %s, =================================================,\n\n", text(releaseType.asUpperCase, "_"), nextVersionDate); |
There was a problem hiding this comment.
Why append the underscore to the releaseType separately, instead of putting the underscore in the format string? Did you mean to make the releaseType including underscore optional?
There was a problem hiding this comment.
Why tie the name of a command-line switch to the name of a DDoc template?
| if (!revRange.empty) | ||
| { | ||
| if (useNightlyTemplate) | ||
| w.put("$(BR)$(BIG $(RELATIVE_LINK2 bugfix-list, List of all upcoming bug fixes and enhancements.))\n\n"); |
There was a problem hiding this comment.
I don't understand how this really simplifies generation, and I think saying "list of things in $VERSION" when $VERSION hasn't been released yet is a little bit worse?
| changedRepos.each!(x => x.changes.writeTextChangesBody(w, x.headline)); | ||
|
|
||
| if (revRange.length) | ||
| if (revRange.empty) |
There was a problem hiding this comment.
Err, did you mean to negate this?
We can also add a beta flag, of course, but it just felt wrong to arbitrarily limit the input. FYI Martin has talked about planning to change the release process to match semantic versioning soon.
This script is solely used for dlang.org (it should imho actually be part of that repository), so the deprecation was just because it wasn't hard to maintain the current behavior and to avoid breaking dlang.org before the other PR has been merged. I would have removed it afterwards to keep things clean and without unnecessary baggage.
Don't worry - it wasn't a full day!! |
Isn't the script also used by the release manager (Martin) to build the static changelog page for a release? |
Yes, but I think/hope that he uses the |
|
I'd like to stick with the previous mechanism, remove any notion of different release types from the changed tool, and use different macros in dlang.org's makefile for |
|
Superseded by #252 |
4 participants
It will forward the logic to a DDoc template.