|
Rockbox mail archiveSubject: Re: Branch for updated/initial bootloaders for USB-enabled PP and AMS Sansas (and their installers)Re: Branch for updated/initial bootloaders for USB-enabled PP and AMS Sansas (and their installers)
From: Dave Chapman <dave_at_dchapman.com>
Date: Wed, 08 Jul 2009 18:27:55 +0100 Thomas Martitz wrote: > Late reply. I don't see any problem with the branch anyway. Any time would have been too late, as you had already created the branch... Just because you don't see a problem with the branch, doesn't mean no-one else does/will. > Anyway, I didn't know the usual way of doing bootloader releases. But > since we're branching for Rockbox releases, and many (including some > almost supported) targets are affected (and due to the point below), I > thought branching was a good idea. Yes, Rockbox releases have always been branched, bootloader releases never have. >> For bootloaders, version numbers don't need committing - they have >> always just been specified when building the binaries. e.g. "make >> VERSION=3.0". >> >> Dave. > > That's just bad IMO. Someone checks out the tag to recompile the release > bootloader for whatever reason and doesn't get the same as installing it > from the download server. The source the binary is built from should > have the version also IMO, that's clearer than implying knowledge of > some make parameters. I agree that's a downside of the current method, but it's simple, bootloader releases are rare, and we actively discourage users from building their own. Of course, I wouldn't object to a method that lets us commit a version number into the source, but shouldn't that be developed first, and then the branch made, just prior to the release? It just seems that the branch was made too early, with too many commits now needing to be made in both the branch and trunk. Dave. Received on 2009-07-08 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |