I could run all my ExternalPackage tests against 4.3... if I updated
4.3's Installer a bit. What's the best way of doing this? I could just fire up 4.3, load Installer-Core-fbs.361 and commit that to squeak43, but I'm not sure that's the best thing to do. frank |
Are you wanting to make a post-release fix for 4.3? Just committing
it to the squeak43 repository should do the trick for that. Or, something else? On Mon, Mar 25, 2013 at 10:44 AM, Frank Shearar <[hidden email]> wrote: > I could run all my ExternalPackage tests against 4.3... if I updated > 4.3's Installer a bit. > > What's the best way of doing this? I could just fire up 4.3, load > Installer-Core-fbs.361 and commit that to squeak43, but I'm not sure > that's the best thing to do. > > frank > |
Post-fix release: specifically, I want 4.3's Installer to be able to
load packages with descriptions like 'Control (1.2)'. At the moment it tries to load a package 'Control ', which of course fails. I certainly could just commit to squeak43. I'm asking how exactly I should do that. Installer-Core-fbs.361 is quite a few versions ahead of 4.3, so should I rather copy each of the interim mczs? frank On 25 March 2013 20:02, Chris Muller <[hidden email]> wrote: > Are you wanting to make a post-release fix for 4.3? Just committing > it to the squeak43 repository should do the trick for that. > > Or, something else? > > > On Mon, Mar 25, 2013 at 10:44 AM, Frank Shearar <[hidden email]> wrote: >> I could run all my ExternalPackage tests against 4.3... if I updated >> 4.3's Installer a bit. >> >> What's the best way of doing this? I could just fire up 4.3, load >> Installer-Core-fbs.361 and commit that to squeak43, but I'm not sure >> that's the best thing to do. >> >> frank >> > |
> Post-fix release: specifically, I want 4.3's Installer to be able to
> load packages with descriptions like 'Control (1.2)'. At the moment it > tries to load a package 'Control ', which of course fails. By "packages" I hope you don't mean simple Monticello .mcz packages. IMO mcz filenames should follow restrictive formatting rules defined by MCVersionName so that MC can be the best at low-level SCM as it can be while keeping the code maintainable. > I certainly could just commit to squeak43. I'm asking how exactly I > should do that. Installer-Core-fbs.361 is quite a few versions ahead > of 4.3, so should I rather copy each of the interim mczs? If there have been a lot of changes perhaps Backporting that one fix is appropriate? I don't have any experience with it, but there is a Backport button on MC. If you don't backport, then I'm on the fence about whether to duplicate the files in the squeak43 repository. The main advantage would be for diffing in that repository, but as 4.3 gets older that will be a rare activity.. |
On 26 March 2013 16:08, Chris Muller <[hidden email]> wrote:
>> Post-fix release: specifically, I want 4.3's Installer to be able to >> load packages with descriptions like 'Control (1.2)'. At the moment it >> tries to load a package 'Control ', which of course fails. > > By "packages" I hope you don't mean simple Monticello .mcz packages. > IMO mcz filenames should follow restrictive formatting rules defined > by MCVersionName so that MC can be the best at low-level SCM as it can > be while keeping the code maintainable. I mean SqueakMap packages. 4.3 expects versioned package names to be of the form "Foo(1)", and blows up if you use proper whitespacing, like all right-thinking people do, in the form of "Foo (1)". 4.4 and 4.5 already both respect sensible whitespacing. >> I certainly could just commit to squeak43. I'm asking how exactly I >> should do that. Installer-Core-fbs.361 is quite a few versions ahead >> of 4.3, so should I rather copy each of the interim mczs? > > If there have been a lot of changes perhaps Backporting that one fix > is appropriate? I don't have any experience with it, but there is a > Backport button on MC. > > If you don't backport, then I'm on the fence about whether to > duplicate the files in the squeak43 repository. The main advantage > would be for diffing in that repository, but as 4.3 gets older that > will be a rare activity.. I suppose I'm half asking whether Monticello package names should have any meaning across repositories. Would people expect Installer-Core.fbs.999 in squeak43 to mean the same thing as Installer-Core.fbs.999 in squeak44? _I'd_ expect not (in which case the right thing to do is backport the one change I want), but my question is what _others_ expect. frank |
> I suppose I'm half asking whether Monticello package names should have
> any meaning across repositories. Would people expect > Installer-Core.fbs.999 in squeak43 to mean the same thing as > Installer-Core.fbs.999 in squeak44? _I'd_ expect not (in which case > the right thing to do is backport the one change I want), but my > question is what _others_ expect. It's the 99% case that Monticello version names are unique, but the UUID of the PackageInfo is all MC has for truly unique identification. I think code should try to rely on the uuid and not on the names being unique, but sometimes there may be no other way to achieve a particular goal.. |
On 26 March 2013 16:28, Chris Muller <[hidden email]> wrote:
>> I suppose I'm half asking whether Monticello package names should have >> any meaning across repositories. Would people expect >> Installer-Core.fbs.999 in squeak43 to mean the same thing as >> Installer-Core.fbs.999 in squeak44? _I'd_ expect not (in which case >> the right thing to do is backport the one change I want), but my >> question is what _others_ expect. > > It's the 99% case that Monticello version names are unique, but the > UUID of the PackageInfo is all MC has for truly unique identification. > > I think code should try to rely on the uuid and not on the names being > unique, but sometimes there may be no other way to achieve a > particular goal.. So just as a follow-up, I took the approach of porting all the intermediate MCZs. That means that squeak43 has Installer-Core-fbs.361, which necessitated upgrading Monticello to Monticello-bf.494. I was lucky: I didn't have to upgrade anything more. But it could have been much worse. In future I recommend backporting only the exact change that you want, and no more. (The Monticello upgrade was necessitated by Installer using #packageAndBranchName.) frank |
Free forum by Nabble | Edit this page |