+1 !!!
I think this is a GREAT proposal, and we can also then hopefully do the
equivalent of grep'ing the commits to identify things that we might want
to incorporate in a high-level set of release notes. I also really like
the "no" requirement. Also, storage changes should really NOT be taken
lightly - they seriously inconvenience our customers and will hopefully
cause the tests to fail (the ones that check for backward-compat) - I
would like to set storage changes actually be voted on, ideally, if we
could make that part of our operating procedure somehow?
Cheers,
Mike
On 6/14/17 9:15 AM, Till Westmann wrote:
Hi,
some of us had a discussion with an SDSC team last week that is
running an
AsterixDB instance. Their customer perspective on AsterixDB highlighted a
few areas of improvement to ease the consumption of AsterixDB.
One thing that I’d like to follow up on are release notes. So far we
didn’t
provide them and so changes to the system came as a surprise to everybody
who is not monitoring commits closely.
As I think that it’s not easy to provide good release notes I’d like to
propose some additions to our commit messages to ease the creation of
release messages:
Each commit message should
1) reference 1 or more JIRA issues (that hopefully provide a rationale
for
the change).
2) contain a description of changes to the user model (language syntax,
configuration parameters, ..)
3) contain a description of storage format changes (that would require
reloading or upgrading)
4) contain a description of interface changes (for source code consumers)
and all reviewers should check that these are mentioned in the commit
message. To increase the probability to we won’t forget to mention the
changes in 2-4, I think that we should should explicitly mention the
absence
of such changes, i.e.:
user model changes: no
storage format changes: no
interface changes: no
Thoughts/concerns about this?
Is this manageable?
Are there other kinds of changes that have a high impact on consumers
that
we should call out?
Cheers,
Till´
