On 02.01.2010 23:25, Steve Borho wrote: > This is a gray area, but this is how I look at it. > > If I make a new tag, I have to make a new tarball so all the other > packagers out there can build their packages for their operating > systems. A 0.9.2.1 tarball would be identical to an 0.9.2 tarball, > except for the version number. This seems very counter-productive.
Sure. I got that. But now other things are counter-productive as well. > We also keep the RPM .spec file in the repository. If the RPM > packager finds a bug in the .spec file after a release, we do not > expect to have to retag the release just to fix the .spec file. I > would expect them to fix the .spec file, make an 0.9.2 rpm file, and > send a fix for inclusion in the stable branch. Given how much we care and do have to care about doing installs on Windows, I don't think it is justified to compare the windows installer delivery item to the RPM's. > The -N postfix on version numbers is a pretty common convention for > 'package respins of a single code release', which is what this was. I don't know what a package respin is, but I don't care that much about tag names. So I am fine with using a tag name like "0.9.2-1". What I care about is not tagging code at all when doing a release. > I think someone looking back at this two years from now could pretty > quickly figure out why an 0.9.2-1 package was made, and which version > of the ISS file was used. If you don't agree with that, the best > course of action would be to make a commit to thg-winbuild that knows > how to regenerate 0.9.2-1 (check out 0.9.2, then get the ISS file from > the very next changeset). Then we could tag that thg-winbuild > changeset with 0.9.2-1. Steve, thanks for the explanation. But it still feels very strange to me. This is not exactly about me disagreeing with something here, it is more about trying to understand how to use mercurial for TortoiseHg itself. TortoiseHg is an interesting example, as it has a quite high complexity regarding platforms, libraries and releases -- despite its rather tiny code base and short history. But I am just amazed how my mental modal of using mercurial is thoroughly violated on TortoiseHg itself in this case. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
