Why not move to something managed/hosted by JIRA or perhaps Github? Patrick
On Fri, Dec 20, 2019 at 2:20 AM Norbert Kalmar <[email protected]> wrote: > +1 on option A. > But! > I think we should have a page containing all the changes in all supported > line. So like option C. > > Why? - I agree a specific release should only contain changes to that > version. If someone wants to see the changes that went into various > releases, he/she should check the website (page that is basically option > C). And a link to this page from releasenotes. > At least that's what I usually see and expect from projects. > But this is based on my personal preference, I don't know what was the > original intention on ZooKeeper, so let's wait for the PMCs to chip in :) > > Thanks for bringing this up Enrico! > > Regards, > Norbert > > On Thu, Dec 19, 2019 at 11:57 PM Enrico Olivelli <[email protected]> > wrote: > > > Hi, > > I am preparing release notes for 3.6.0, > > as branch-3.6 has been cut from master branch I found that > > releasenotes.mdtalk about ZooKeeper 3.0.0 !! > > > > > > > https://github.com/apache/zookeeper/blob/master/zookeeper-docs/src/main/resources/markdown/releasenotes.md > > > > I found also that when I wrote the release notes of 3.5.6 I had only > > committed them to branch-3.5.6 and not to branch-3.5. > > I have fixed branch-3.5 by adding the release notes for 3.5.6. > > > > Then I found that in branch-3.5 we only have the release notes from 3.5.0 > > to 3.5.6 so we are missing the release notes for 3.4, 3.3..... > > > > here is it the public website: > > http://zookeeper.apache.org/doc/r3.5.6/releasenotes.html > > > > If you see release notes of 3.4.14 you will see ONLY notes about 3.4 > > release line > > http://zookeeper.apache.org/doc/r3.4.14/releasenotes.html > > > > is this intentional? > > > > > > If this is not intentional I suggest these ways: > > A) let every release hold only the specific changes for that release (so > in > > 3.4.14 I would see ONLY 3.1.14 news) > > B) let every release hold all of the changes from the beginning of the > > project up to that version > > C) like B),but keep only latest supported release line, so keep the > history > > from 3.4 up to the current version > > > > I think that the best option is A): > > - the list won't grow without bounds > > - in the "relases notes" page you see only news about that version > > > > > > Enrico > > >
