Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changelog is malformatted and missing releases #142

Open
sam-github opened this issue Nov 20, 2019 · 10 comments
Open

changelog is malformatted and missing releases #142

sam-github opened this issue Nov 20, 2019 · 10 comments

Comments

@sam-github
Copy link

https://www.openssl.org/news/changelog.html

Changes between 1.1.1 and 3.0.0 [xx XXX xxxx]
Changes between 1.1.1a and 1.1.1b [xx XXX xxxx]
Changes between 1.1.1 and 1.1.1a [20 Nov 2018]
Changes between 1.1.0i and 1.1.1 [11 Sep 2018]
Changes between 1.1.0h and 1.1.0i [xx XXX xxxx]

1.1.1c and d are missing, and the timestamps are missing.

@paulidale
Copy link
Contributor

@mattcaswell / @levitte does this mean there is a step missing in the release process documentation?

@levitte
Copy link
Member

levitte commented Nov 21, 2019

It means that there's a disconnect between CHANGES in the master branch and CHANGES in 1.1.1. We've been staggeringly sloppy with those files in the last few years.

@levitte
Copy link
Member

levitte commented Nov 21, 2019

What's happening in practice is that while the CHANGES in 1.1.1 is better for 1.1.1, we're using CHANGES from master on our web site, for all releases. We need to rethink that, 'cause that causes a disconnect between what's on our web site and what's on the actual release.

@levitte
Copy link
Member

levitte commented Nov 21, 2019

This is, BTW, a web problem, so I'm moving this over to that repo (on of github's newer features)

@levitte levitte transferred this issue from openssl/openssl Nov 21, 2019
@levitte
Copy link
Member

levitte commented Nov 21, 2019

Upon closer inspection of the web page, it does have an explanation:

When a release is created, that branch is forked off, and its changelog is also forked. For example, none of the changes after 0.9.8n appear in the other logs, because 1.0.0 was created after that release and before 0.9.8o. Any changes that are merged across branches, however, should have an entry in each branch's changelog.

... and there are links to the release specific changelogs, which are much more accurate for those releases

So this comes down to a presentation issue. We might want to discuss this within the OMC.

@mspncp
Copy link
Contributor

mspncp commented Nov 21, 2019

Regardless of release policy documentation issues, I still would say that the following two lines shouldn’t be in the master branch, because the letter releases of 1.1.1 occurred on the stable branch.

Changes between 1.1.1a and 1.1.1b [xx XXX xxxx]
Changes between 1.1.1 and 1.1.1a [20 Nov 2018]

@mspncp
Copy link
Contributor

mspncp commented Nov 21, 2019

Changes between 1.1.1a and 1.1.1b [xx XXX xxxx]
Changes between 1.1.1 and 1.1.1a [20 Nov 2018]

If a fix gets simultaneously added to themaster branch and cherry-picked to the OpenSSL_1_1_1-stable branch (say, for release 1.1.1x) then in theory it would be an option to associate the CHANGES entry with 1.1.x in both branches. But in practice this would make the bookkeeping and merging of the CHANGES file even more complicated, and I don't recall this was ever done this way previously.

@mattcaswell
Copy link
Member

Regardless of release policy documentation issues, I still would say that the following two lines shouldn’t be in the master branch, because the letter releases of 1.1.1 occurred on the stable branch.

IMO CHANGES from 1.1.1 branch should be mirrored on the master branch up until 3.0 gets released. At that point CHANGES in the 3.0 branch only gets updated with CHANGES specific to that branch.

@mspncp
Copy link
Contributor

mspncp commented Nov 21, 2019

IMO CHANGES from 1.1.1 branch should be mirrored

But not all fixes (resp. features) in master will be backported. So we end up having to separate the entries on master until 3.0 gets released, as described in #142 (comment).

@mattcaswell
Copy link
Member

But not all fixes (resp. features) in master will be backported. So we end up having to separate the entries on master until 3.0 gets released, as described in #142 (comment).

Yes. There will be a section on CHANGES from 1.1.x to 3.0. Underneath that will be the list of CHANGES applying to the 1.1.1 branch. As it is now (only updated).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants