You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Patrick Hunt <ph...@apache.org> on 2020/01/02 23:59:57 UTC

Re: Messy releasenotes.md file on master and on website

Thanks Enrico. I was thinking about the following, which I'm not sure is
valid but an idea: can't we just link to the release notes on the JIRA
(etc...) rather than having a copy as part of the release?

e.g.
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12345243

and more generally all available via :
https://issues.apache.org/jira/projects/ZOOKEEPER?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=no-filter

We could also link to something like:
https://github.com/apache/zookeeper/releases/tag/release-3.5.6

One reason I like this is if we notice and issue with the release notes
post-release we could update them to reflect any issues (typically
forgetting to include some details in the release notes...)

If we made some minor changes to our release process we could probably also
have something like what k8s does:
https://github.com/kubernetes/kubernetes/releases/tag/v1.16.4
e.g. release notes, plus a changelog which we generate, etc... Again, we
would just link to this URL rather than copy/paste into the release itself.

Not sure if that's kosher per Apache, iirc in the early days (10 yrs ago)
it wasn't, but times change...

Patrick

On Sat, Dec 28, 2019 at 9:20 AM Enrico Olivelli <eo...@gmail.com> wrote:

> Patrick,
>
> Il ven 20 dic 2019, 21:56 Patrick Hunt <ph...@apache.org> ha scritto:
>
> > Why not move to something managed/hosted by JIRA or perhaps Github?
> >
>
> Can you elaborate more please?
>
> We are coping release notes from JIRA.
> We can copy them to github releases page.
> But I think that a page on the website is useful
>
> Enrico
>
> >
> > Patrick
> >
> > On Fri, Dec 20, 2019 at 2:20 AM Norbert Kalmar
> > <nk...@cloudera.com.invalid>
> > 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 <eo...@gmail.com>
> > > 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
> > > >
> > >
> >
>