Re: How to fix roundup.org's customizing.txt
Ralf Schlatterbeck <[email protected]>
| Newsgroups | gmane.comp.bug-tracking.roundup.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Sep 07, 2018 at 09:07:32AM +0200, Thomas Arendsen Hein wrote: > * John P. Rouillard <[email protected]> [20180906 23:27]: > > > 3) branch the doc in hg (to 1.6.0_branch), roll back the gpg/pyme > > change and publish that. Advantage: in hg and reproducable if we > > need to do another 1.6.x release not based on trunk, working > > example and url's. Disadvantage: not the same as released 1.6.0, > > need to figure out how to do the required hg work. > > My suggestion here would be to to a 1.6 branch, branching off at > the 1.6.0 tag that will lead to a 1.6.1 release at some point. Thanks Thomas for the detailed instructions. I also prefer 3) > P.S.: Can anyone here tell me how above can be done with git? the equivalent of graft is 'cherry-pick' with git. Creating a branch from an already-existing tag is left as something basic as an exercise to the reader The additional merge step is not necessary with git For maintenance I'd prefer to commit all fixes to head and only cherry-pick selected changes to the release branch. Not commit them to the relase branch and merge to head, but that's just a preference that can be realized with git or mercurial. The problem for me with mercurial -- maybe like for you with git -- is that I know my way around with git and always have to look up things with mercurial. A git-to-mercurial cheat sheet would be a great help here. Some things -- like rebasing -- to my knowledge can't currently be done with mercurial. This makes it hard to maintain features (like in our case the REST API implementation from GSOC) without clogging them up with frequent merge-changes from head. At least in the Linux development, keeping a new feature that is not yet accepted upstream in a state that applies to head but only has the necessary feature-related changes is something that makes life easier for all people involved. Also interactive rebase to clean up local changes before pushing them is a feature I miss with mercurial. Not to speak of a staging step before commit (git add then git commit) and stashing changes. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot