Re: Marc Haber 2018-08-19 <20180819185517.gl5...@torres.zugschlus.de> > I'm trying to avoid > > Case 1: Somebody working on the branch, committing things and generating > new changelog entries for a version (x-y) that is already in the archive and > should therefore not be changed in the vcs
"dch" will take care of automatically incrementing the version number if the distribution is not UNRELEASED. > Case 2: Somebody working on the branch with a new version (x-y+1), > deploying test versions of the package that will not be overwritten by > later versions of the package (with the same version number) from the > archive, with the side effect that different but identically numbered > versions of the packages fly around. I think the proper fix if that behavior is desired is 1) tell dch to produce a .0 (I'd prefer ~unrel) version number (and have "dch -r" remove it) and 2) only generate this changelog entry with the first change, i.e. leave git unmodified until the first change happens. > Additionally, the tracker would > begin to remind uploading those versions. It should not nag about uploading, just remind that there's pending changes. I think this is the major issue here. It's a maintainer decision if pending changes warrant an upload, not an automated system's one. I don't think we can easily tell this case from various other edge cases apart in vcswatch. If there's a new changelog entry, or commits since the last tag, it needs to raise "NEW" or "UNREL". Christoph
