Re: changelog practice, unfinalised vs UNRELEASED vs ~version
On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> Simon McVittie <smcv@debian.org> writes:
> > This works fine if every commit is final and immutable and is sent
> > directly to the master VCS immediately, but works very poorly if you
> > are proposing commits for someone else to merge at a later date -
>
> I don't see how this complaint is any different from the need to merge,
> for example, changes to API documentation and test cases that accompany
> a functional change.
It's the difference between "sometimes conflicts" and "always conflicts".
If Alice and Bob are concurrently updating API documentation and test
cases, and they aren't particularly unlucky or working on particularly
adjacent bits of code, Alice's changes will often not touch exactly the
same parts of the same files as Bob's changes. (If they are working on
adjacent code then they probably need to be talking to each other
anyway.)
If they are concurrently updating debian/changelog or a GNU-style
ChangeLog at the same as developing and documenting, the right place
for Alice to document recent changes (appending to the non-finalized
debian/changelog entry, or prepending to a GNU ChangeLog) is exactly the
same as the right place for Bob to document recent changes, guaranteeing
a collision.
> I'm in agreement with Ian that the “write the documentation (including
> the changelog) along with the change it describes” workflow should have
> full support from our tools.
Are you making the stronger assertion, as Ian seems to be, that this
workflow should be the *only* thing that has full support from our tools?
I am not against tools supporting writing the changelog in advance;
that's what I mostly still do in my own Debian packages, although I am
increasingly unconvinced that it's the best model in general. I *am*
against tools that aim to be universally used, but *only* support that
model of operation.
S
Reply to: