On Thu, 1 Dec 2016 07:00:17 -0800 Yong Bakos <j...@humanoriented.com> wrote:
> Hi Pekka, > > > On Dec 1, 2016, at 3:54 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > > > From: Pekka Paalanen <pekka.paala...@collabora.co.uk> > > > > We should probably have a change log in the tree to list the changes > > that end users (of weston, libweston, libweston-desktop, the apps, etc.) > > might be interested in. Particularly we can list changes to e.g. command > > line options, config file options and such which might require people to > > change their configs. > > > > All the earlier releases I just punted with a link to the list of > > release notes. I skimmed through all the changes since 1.12.0 was > > released and wrote them down to give an example of what we might list > > here. I probably missed something, too. > > > > The heading is "The Next Release" because when we cut a release, we > > don't know what version the next release will be. Right now we do know > > it will be 2.0.0, but in general we don't know. > > > > When doing a release, I would expect one to just add a new heading with > > the release number, leaving "The Next Release" section empty again. > > > > Cc: Bryce Harrington <br...@osg.samsung.com> > > Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk> > > I ACK the series, but some suggestions below. Let's set a precedent for > the format. Some interesting ideas here: > > http://keepachangelog.com/en/0.3.0/ Hi, that's a nice page. > https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md > > If I'm being to formal about this just ignore me. :) > > > --- > > NEWS | 20 ++++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > create mode 100644 NEWS > > > > diff --git a/NEWS b/NEWS > > new file mode 100644 > > index 0000000..368cf71 > > --- /dev/null > > +++ b/NEWS > > @@ -0,0 +1,20 @@ > > +The Next Release > > +================ > > How about "Unreleased". Perhaps some of these features listed won't > actually make it, for one reason or another, in the actual release. Sure, why not. But if a feature does not make it, the revert of the commits should also revert the log entry. > > + > > +* libweston: add "move without scaling" animation type > > +* Support desktop-shell panel on the left, right and bottom > > +* xdg-shell-v6 support in the Wayland backend (i.e. nested libweston) > > +* Support WL_SHM_FORMAT_YUYV > > +* A Weston configuration option to allow starting without input devices > > +* XKB compose key support in the demo clients > > +* Support WL_SHM_FORMAT_NV12 > > +* Support WL_SHM_FORMAT_YUV420 > > +* Support DRM_FORMAT_YUV444 > > +* Changed API for output configuration in libweston > > + > > + > > +Older and stable releases, including 1.12.0 > > Let's separate this into 1.12.0 with a date, and then another > header for the older stuff. That way we have a precedent for the > release version/date header and the features list. eg: > > 1.12.0 - 2016-09-20 > =================== > > * feature list item to set some precedent > * and another That's cool, I just couldn't bother going through whole that period too. The date is a very good point. I have cursed the lack of dates myself a lot of times. > > > Older Releases > ============== > > See the release notes at https://wayland.freedesktop.org/releases.html Right. What I wanted with this patch is to create a place where we can note when we change command line and config file options, since there are some patches waiting that do that. Thanks, pq
pgpIRsS5vzs97.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel