On 06.08.2015 07:30, Brett Cannon wrote:
> If we ever want to have a nice workflow where we can automate as much as
> possible, we need to figure out a way deal with our most common merge
> conflict: Misc/NEWS. Thanks to shifts in the format between different minor
> versions the file is pretty much guaranteed to have a conflict when doing a
> merge up a version.
>
> So how do we solve this? I can remember 3 possible solutions that have been
> proposed previously:
>
> 1. A single file per entry
> 2. A single file per release version of Python
> 3. Automating it based on commit messages
I had mentioned a fourth one:
4. Add a NEWS field to the issue tracker and use it's content
for the file entry
This is how eGenix does it and it's been working great so far.
We simply have our issue tracker generate a report and use
this as basis for the change log when cutting a release.
It also takes care of categorization since we can just grab that from the Components field.
The advantage over checkin messages is that you are not stuck
if you have multiple checkins for a single issue which should
only have a single entry in the change log.
Without using the issue tracker, this is similar to approach
#2 you mentioned above, but with only creating that file
once during the release process instead of patching it up with
every single checkin.
The only drawback I see to this is it will require an issue for every change that should go into the changelog. Now I actually think that's a good thing, but I can see some pushback from python-dev by those who don't want the hassle. But I would argue that any change significant enough to warrant an entry in the changelog warrants an issue to track it.
-Brett
> I personally prefer #3 as I hate repeating myself since I just copy and
> paste the first line(s) of my commits to Misc/NEWS as it is anyway
> (basically up to the first pair of newlines). We would need a way to signal
> that the commit message contains nothing useful for the to-be-generated
> NEWS file when it's simply a fix for a previous commit (probably some
> marker that is somewhat inconspicuous like a dash on its own line or
> something). In terms of the section of the NEWS file that a commit belongs,
> that can once again be a marker or honestly something we drop or infer
> based on what files were edited in the commit.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 06 2015)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/