4.4 release plan
Locked
 
|
Hi,
We've had a sharp uptick in the rate of development recently, and I thought it worthwhile to talk about how this might go forward. I'd originally wanted Environments in 4.4 because I like new features in versions, rather than (and my perception might be completely wrong) lots of bugfixes [1]. In talking to Colin, that was a tad optimistic, given that Chris Cunnington and I were talking about a September release. Since I'd like to increase the perceived momentum of Squeak, I'd thus rather release 4.4 now than wait for us to hammer on Environments. Colin reckons he'd like to adjust Environments over the next few months. Given the invasiveness of the change (even if it has had very little impact so far), that seems like a good plan. Solid release, good. Flaky release, bad. So, the plan right now is * unwind Environments * move 4.4 into beta * get a green light on all tests (that we expect to work now) (* ideally test a bunch of well-known packages against 4.4 on squeakci) * release 4.4 on September 1. I don't know if that means we should simply fork 4.4 backdated immediately prior to Environments landing or not: if that's possible, that might be easier than unwinding. I would ask, though, that people concentrate on hammering the 4.4 beta stream then, rather than hammering on trunk, until September. frank [1] At some point I'll do the hard graft of formalising these features/fixes into a changelog. |
|
|
On Thu, 2 Aug 2012, Frank Shearar wrote:
> Hi, > > We've had a sharp uptick in the rate of development recently, and I > thought it worthwhile to talk about how this might go forward. > > I'd originally wanted Environments in 4.4 because I like new features > in versions, rather than (and my perception might be completely wrong) > lots of bugfixes [1]. > > In talking to Colin, that was a tad optimistic, given that Chris > Cunnington and I were talking about a September release. > > Since I'd like to increase the perceived momentum of Squeak, I'd thus > rather release 4.4 now than wait for us to hammer on Environments. > Colin reckons he'd like to adjust Environments over the next few > months. Given the invasiveness of the change (even if it has had very > little impact so far), that seems like a good plan. Solid release, > good. Flaky release, bad. > > So, the plan right now is > * unwind Environments > * move 4.4 into beta > * get a green light on all tests (that we expect to work now) > (* ideally test a bunch of well-known packages against 4.4 on squeakci) Would be nice. I tried Fuel recently, but Environments break it (it assumes that Smalltalk globals understands the SystemDictionary protocol) and there's also some Pharoism (no clean loading because of this) there which results in plenty of test failures and errors. > * release 4.4 on September 1. > > I don't know if that means we should simply fork 4.4 backdated > immediately prior to Environments landing or not: if that's possible, I doubt it's a good idea, unless you want to maintain two branches (Trunk & 4.4 beta). The Trunk always goes forward, so if you want to "roll back" Environments there, then you'll have to unload the new packages (don't forget to bumb VersionNumber) and push new versions of existing ones which have the old behavior. > that might be easier than unwinding. I would ask, though, that people > concentrate on hammering the 4.4 beta stream then, rather than > hammering on trunk, until September. Keeping a single branch (Trunk) is better, because everyone will concentrate on that one. Maintaining two branches is a lot of effort IMHO. > > frank > > [1] At some point I'll do the hard graft of formalising these > features/fixes into a changelog. Sounds great. Levente > > |
|
|
On 02.08.2012, at 05:07, Levente Uzonyi wrote: > On Thu, 2 Aug 2012, Frank Shearar wrote: > >> Hi, >> >> We've had a sharp uptick in the rate of development recently, and I >> thought it worthwhile to talk about how this might go forward. >> >> I'd originally wanted Environments in 4.4 because I like new features >> in versions, rather than (and my perception might be completely wrong) >> lots of bugfixes [1]. >> >> In talking to Colin, that was a tad optimistic, given that Chris >> Cunnington and I were talking about a September release. >> >> Since I'd like to increase the perceived momentum of Squeak, I'd thus >> rather release 4.4 now than wait for us to hammer on Environments. >> Colin reckons he'd like to adjust Environments over the next few >> months. Given the invasiveness of the change (even if it has had very >> little impact so far), that seems like a good plan. Solid release, >> good. Flaky release, bad. >> >> So, the plan right now is >> * unwind Environments >> * move 4.4 into beta >> * get a green light on all tests (that we expect to work now) >> (* ideally test a bunch of well-known packages against 4.4 on squeakci) > > Would be nice. I tried Fuel recently, but Environments break it (it assumes that Smalltalk globals understands the SystemDictionary protocol) and there's also some Pharoism (no clean loading because of this) there which results in plenty of test failures and errors. > >> * release 4.4 on September 1. >> >> I don't know if that means we should simply fork 4.4 backdated >> immediately prior to Environments landing or not: if that's possible, > > I doubt it's a good idea, unless you want to maintain two branches (Trunk & 4.4 beta). The Trunk always goes forward, so if you want to "roll back" Environments there, then you'll have to unload the new packages (don't forget to bumb VersionNumber) and push new versions of existing ones which have the old behavior. > >> that might be easier than unwinding. I would ask, though, that people >> concentrate on hammering the 4.4 beta stream then, rather than >> hammering on trunk, until September. > > Keeping a single branch (Trunk) is better, because everyone will concentrate on that one. Maintaining two branches is a lot of effort IMHO. > >> >> frank >> >> [1] At some point I'll do the hard graft of formalising these >> features/fixes into a changelog. > > Sounds great. > > > Levente > >> >> Hear hear. - Bert - |
|
|
In reply to this post by Frank Shearar-3
On Thu, Aug 2, 2012 at 3:05 AM, Frank Shearar <[hidden email]> wrote:
> So, the plan right now is > * unwind Environments Ok, so how do we do this? I'd guess something like the following: • remove update 216 • add a new update that removes environments if they are present Does that make sense? Colin |
|
|
On 02.08.2012, at 11:01, Colin Putney wrote: > On Thu, Aug 2, 2012 at 3:05 AM, Frank Shearar <[hidden email]> wrote: > >> So, the plan right now is >> * unwind Environments > > Ok, so how do we do this? I'd guess something like the following: > > • remove update 216 > • add a new update that removes environments if they are present > > Does that make sense? > > Colin Can we just make them inactive again for the release without removing the code? - Bert - |
|
|
On Thu, Aug 2, 2012 at 11:36 AM, Bert Freudenberg <[hidden email]> wrote:
Can we just make them inactive again for the release without removing the code? I suppose so, although the only benefit of that would be less churn in the update stream. The code in the trunk is a subset of what was in my demo image, so it's not going to work outside of Smalltalk globals.
|
|
|
In reply to this post by Colin Putney-3
On Thu, 2 Aug 2012, Colin Putney wrote:
> On Thu, Aug 2, 2012 at 3:05 AM, Frank Shearar <[hidden email]> wrote: > >> So, the plan right now is >> * unwind Environments > > Ok, so how do we do this? I'd guess something like the following: > > • remove update 216 We can't remove updates from Trunk without breaking all updated images, so that won't work (we don't want to break the "update button"). So, going forward is the way to do it. Push a new versions of the packages which simply revert the changes. If something has to be unloaded, then bump the version number of the VersionNumber package to ensure that the update number will be higher than the previous one. Levente > • add a new update that removes environments if they are present > > Does that make sense? > > Colin > > |
|
|
On Thu, 2 Aug 2012, Levente Uzonyi wrote:
> On Thu, 2 Aug 2012, Colin Putney wrote: > >> On Thu, Aug 2, 2012 at 3:05 AM, Frank Shearar <[hidden email]> >> wrote: >> >>> So, the plan right now is >>> * unwind Environments >> >> Ok, so how do we do this? I'd guess something like the following: >> >> • remove update 216 > > We can't remove updates from Trunk without breaking all updated images, so > that won't work (we don't want to break the "update button"). So, going > forward is the way to do it. Push a new versions of the packages which simply > revert the changes. If something has to be unloaded, then bump the version > number of the VersionNumber package to ensure that the update number will be Levente > higher than the previous one. > > > Levente > >> • add a new update that removes environments if they are present >> >> Does that make sense? >> >> Colin >> > |
|
|
On Thu, Aug 2, 2012 at 1:13 PM, Levente Uzonyi <[hidden email]> wrote:
That's why I suggested adding a new update that removes environments if they're present. (Perhaps removing 216 really means replacing it with a no-op.) So images that haven't been updated yet, will get a pair of no-ops, while updated images will get a new update that reverses the previous one.
Sure, for updated images we reverse the previous changes. But I'd like to leave the existing SystemDictionary in place for un-updated images if we can manage it. Colin |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |