web
web copied to clipboard
openssl
changelog is malformatted and missing releases
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.
@mattcaswell / @levitte does this mean there is a step missing in the release process documentation?
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.
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.
This is, BTW, a web problem, so I'm moving this over to that repo (on of github's newer features)
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.
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]
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.
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.
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 https://github.com/openssl/web/issues/142#issuecomment-557018668.
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).