@JonathanGregory which PR is associated with this issue? I don't see one linked.
--
Reply to this email directly or view it on GitHub:
Please could someone merge this pull request, which qualifies for acceptance
today. Thanks.
--
Reply to this email directly or view it on GitHub:
@erget commented on this pull request.
> @@ -0,0 +1 @@
+:current-version: 1.10
I don't have overly strong feelings here, but in the absence of Sturm und Drang
from other corners my preference would be to go with using `current-version`
for the whole shebang. Reasoning:
- It's simpler than
Aha! Quite right. I did only half the job. :-) I will write the PR.
--
Reply to this email directly or view it on GitHub:
@davidhassell ping - thoughts here? (1) is a very good question - is there an
easy way to generate such an overview in the absence of updates to the history
section of the document? I imagine GitHub would be helpful, and it might be
even easier if we use milestones that could be attached to PRs
I prefer the more terse formulation. Replacing the space with a dash, so
`1.10-draft`, would be similar to a well known pattern for software versioning
of appending `-SNAPSHOT` or `-mmddhhss` to a version number. Perhaps a bit
more obvious than `1.10 draft` but still terse.
--
Reply to
I agree, per-release headers in History would be helpful.
@JonathanGregory - I like the idea of closing inactive issues after some period
of dormancy and adding a "No change agreed" label to those issues. I also like
the idea of adding a "Change agreed" label to issues as they are agreed (and
See issue #129 for discussion of these changes.
- [N/A] Authors updated in `cf-conventions.adoc`?
- [N/A] Next version in `cf-conventions.adoc` up to date? Versioning inspired
by
The PR is
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/346__;!!G2kpM7uM-TzIFchu!l4h76Wxxnb3d7vg0CfHEc_Q6ifhKedEAAGxCk42s6xr2QZgkgpdY8Q1s7upJsWX9bde5KuXOMKE$
--
Reply to this email directly or view it on GitHub:
Personally, I'm more for the terser formulation of `draft` - IMO that makes it
obvious enough.
--
Reply to this email directly or view it on GitHub:
Thanks
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/129*issuecomment-1006663320__;Iw!!G2kpM7uM-TzIFchu!inhZSwNqcSngidTPij8gVZ1YpNxYhO5xE3JBYPtrTLoXrxpCrW89S7d3dLzvQakqCJ5qOTWe5FY$
You are receiving this
Thanks, Jonathan - The PR looks fine to me.
--
Reply to this email directly or view it on GitHub:
@castelao : thanks, I agree with your approach. Following the theme of keeping
things simple unless there is a clear need, I suggest using your listed fields
plus `Description` for now, and more can be added later if needed.
--
Reply to this email directly or view it on GitHub:
For reference, in ESMValTool we use just the process that @erget described to
generate the changelog using [this
@martinjuckes , thanks for raising this point. I think it is a good idea to
have a description associated with the DOI. To clarify, Zenodo is quite
convenient and I've been a happy user but the price is that we must conform
with their resources. A direct DOI registration provides more fields
> @JonathanGregory I agree that a per-release entry in History would make sense.
OK. If others agree, this is something we could introduce in 1.10, and it might
not be too hard to insert those headings for all the previous versions.
> What you propose regarding labels would work, although it
@zklaus pushed 1 commit.
1bae8aead25c12a9b0f7cd0af7cfd636a8ed1ca3 Add -draft suffix to version
--
View it on GitHub:
We could put headings in the history section (in `history.adoc`), starting a
new one in each new release. Thus, the history section in the present draft
would begin with a title something like "Differences between 1.9 and 1.10", and
there would be nothing there. Just to be clear, we could write
I agree with putting `draft` in the current-version. I think it would be a
positive advantage if it turns up e.g. in `Conventions` (in the text of the
draft document), because that makes the status obvious. In fact maybe we could
be more explicit and say e.g. `:current-version: 1.10 draft (not
@JonathanGregory thanks for bringing us back on track!
> Might it make sense to do this?:
>
> :current-version: 1.10 draft
>
> And then remove draft pre-release?
I think that would make sense.
--
Reply to this email directly or view it on GitHub:
@JonathanGregory I agree that a per-release entry in History would make sense.
What you propose regarding labels would work, although it might be simpler if
we track them by pull requests. This is a common pattern in the software
development world. This has been made easy for 1.9 as shown by
@castelao : I like the idea of having a DOI for the CF concept, but I would
like to take this opportunity to clarifying what that concept is. @ethanrd has
suggested, I think, that the concept can be defined, in effect, by pointing to
cfconventions.org, but I feel it would be more in the spirit
Discussion in review comments of
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344__;!!G2kpM7uM-TzIFchu!lLnLFd19gThcoMUaRLU_pBH4VxrLNZCKKoySzJQnQfoNQoRM5jsViIxya-aghDFqq-QhUmVjGFI$
reproduced here for the record. (May I politely and respectfully remind
Thanks @JonathanGregory . If you have no objections, I'll set a reminder to
myself to merge this in 3 weeks (2022-01-27) so that interested parties can
comment on the small modifications to the updated draft in good time.
--
Reply to this email directly or view it on GitHub:
Separately, I would like to suggest that when we close issues in this
repository which have been agreed to be implemented in the next release, we
should add another label that indicates this e.g. "1.9" for all the ones added
to the present version. Those new labels can all be the same colour,
Hello all,
My (current) thoughts on the new release question: I'm not sure about cutting
1.10 to fix just this defect. Given that it can be fixed in the latest CF-1.10
draft, is that not sufficient to tide us over to the whenever CF-1.10 is
released? A few years ago we agreed that one release,
@zklaus pushed 1 commit.
ff0a539a242555b27cd6aa5018e6e9a0c65b1530 Fancify single sourced version
--
View it on GitHub:
I have added a fancified version of the version handling. Let me know what you
think or if you want me to explain a bit more.
--
Reply to this email directly or view it on GitHub:
28 matches
Mail list logo
