On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell wrote:
> Like this?
>
> https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc
>
+1 !
On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk wrote:
>
>> On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell
>> wrote:
>>
>>> I think by git tag would
On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell wrote:
> Like this?
>
> https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc
>
>
>
Looks good to me. 2.3.0 CHANGELOG doesn't display because it is too big --
it is an accumulation of all changes up to 2.3 (good IMO) whereas 2.2+2.1,
Like this?
https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc
On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk wrote:
> On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell
> wrote:
>
>> I think by git tag would work. Given the URL can be different from the
>> visible anchor text we
On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell wrote:
> I think by git tag would work. Given the URL can be different from the
> visible anchor text we could use an exact git sha too, if there is concern
> that tags might be changed either accidentally or intentionally in a way
> that breaks
I think by git tag would work. Given the URL can be different from the
visible anchor text we could use an exact git sha too, if there is concern
that tags might be changed either accidentally or intentionally in a way
that breaks embedded links in old changelogs.
On Tue, Dec 1, 2020 at 11:57 AM
I am in favor of referring off to the changes files of older releases.
Would that be by git tag, or to the files in the distribution archives?
I don’t think these changes files are for marketing as such. However, I
think they are intended to be human-readable (if not for humans, then
who/what,
Unless there is an objection to the plan I described below, it will happen
tomorrow on branch-2 in prep for RC.
> On Nov 30, 2020, at 4:46 PM, Andrew Purtell wrote:
>
>
> I'm glad I checked email before beginning the RC.
>
> How about this:
>
> CHANGES.md file that ships in 2.4.0 will
I'm glad I checked email before beginning the RC.
How about this:
CHANGES.md file that ships in 2.4.0 will contain URLs pointing to older
CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
CHANGES.md file that ships with 2.4.0 will list all issues completed for
2.4.0
CHANGES.md file that ships
On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk wrote:
> So concretely, the conclusion here is that the CHANGES.md file that ships
> in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0?
> The CHANGES.md file that ships in 2.4.1 will contain all of the above, plus
> entries
So concretely, the conclusion here is that the CHANGES.md file that ships
in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0?
The CHANGES.md file that ships in 2.4.1 will contain all of the above, plus
entries for 2.4.1.
Are you sure that's what you want? That seems like
+1 on what Sean proposed to include the changes started from the first
major release.
Sean Busbey 于2020年11月10日周二 下午7:37写道：
> I thought we had written up a guide before for what goes in the changes
> file, but I can't find it at the moment.
>
> For branch 2.3 I am surprised at 0.99 stuff. I
On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey wrote:
> We've talked for some time about possibly including release notes / changes
> for just those things in each individual release on the website before.
> Would adding something like that be sufficient for the use you're thinking
> of?
>
Having
Idea was CHANGEs.md + RELEASENOTES.md would have all changes listed, not
some subset, per Seans' text diagram. Should be accumulative. The build
scripts take care of making the new additions for you.
If the files have become large, lets add links to files that list changes
<1.0.0 and then changes
I thought we had written up a guide before for what goes in the changes
file, but I can't find it at the moment.
For branch 2.3 I am surprised at 0.99 stuff. I would expect:
* 2.0.0
* 2.1.0
* 2.2.0
* 2.3.[0-z]
Because that would be enough that if I was coming from the prior major
release I
+1 for restricting CHANGES.md contents with what’s new after latest release
on the respective release line.
On Tue, 10 Nov 2020 at 3:05 AM, Nick Dimiduk wrote:
> Heya,
>
> The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for
> Github to render. Its content covers back to
Heya,
The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for
Github to render. Its content covers back to 0.99. This isn't really usable
by someone who wants to easily see what's new in the latest patch release.
I propose we truncate these changes files to what's new for the
16 matches
Mail list logo
