On Sat, Jan 2, 2010 at 4:52 PM, Adrian Buehlmann <adr...@cadifra.com> wrote: > 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.
It's difficult to understate the complexity of our installers, as my failures in the last two releases plainly shows. > But I am just amazed how my mental modal of using mercurial is thoroughly > violated on TortoiseHg itself in this case. If you compare TortoiseHg to Mercurial itself, I think we're pretty close. Mercurial also versions their iss file in their repository but they do not tag changes to the ISS file. It all boils down to your point of view on what is being tagged, the product or the package. For Mercurial, a release gets a tag and a tarfile and each platform generates as many package revisions as they need to get their package correct for that release. If your point of view is that TortoiseHg is a Windows installer, then your mental model of things is very consistent. I'd like to think the project is bigger than that, so package rebuilds that are local to Windows should be tracked by thg-winbuild. -- Steve Borho ------------------------------------------------------------------------------ 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 Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
