> > >>>>> "Ken" == Ken G Brown <[hidden email]> writes:
> > > >Ken> You had at least two available starting points, 3.10.2 and 3.10.2-build, > >Ken> -buiild was clearly better and available since June 28, 2009 (before > >Ken> trunk). The fixes and additions to 3.10.2 in -build were clearly > >Ken> documented in the info file on the ftp site, > >Ken> Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. And >Ken> you all are choosing the one that was inferior as a starting point. > > > >I think I could find at least a dozen squeak developers here who > >would agree with me that if 3.10.2-build was a fixed point, it's > >a bad name for a release, and if it was a moving point, it would > >be a bad place to start the legal process. > > > >Had that been released as 3.10.3, or 3.11, your point would have merit. I agree that for 4.0 it is too late to use 3.10.2-build. However, would it be possible to apply trunk to 3.10.2-build instead of 3.10.2 for 4.1? and thus harvest the value in 3.10.2-build? Regards, Ralph Boland |
The whole point of 4.0 is having a license clean base to deploy trunk
changes into (to be released as 4.1) OR: The whole point of 4.0 is to have a license clean base to do whatever else you might want to do with it. On Sunday, March 14, 2010, Ralph Boland <[hidden email]> wrote: >> > >>>>> "Ken" == Ken G Brown <[hidden email]> writes: >> > >> >Ken> You had at least two available starting points, 3.10.2 and 3.10.2-build, >> >Ken> -buiild was clearly better and available since June 28, 2009 (before >> >Ken> trunk). The fixes and additions to 3.10.2 in -build were clearly >> >Ken> documented in the info file on the ftp site, >> >Ken> Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. And >>Ken> you all are choosing the one that was inferior as a starting point. >> > >> >I think I could find at least a dozen squeak developers here who >> >would agree with me that if 3.10.2-build was a fixed point, it's >> >a bad name for a release, and if it was a moving point, it would >> >be a bad place to start the legal process. >> > >> >Had that been released as 3.10.3, or 3.11, your point would have merit. > > I agree that for 4.0 it is too late to use 3.10.2-build. > However, would it be possible to apply trunk to 3.10.2-build instead of > 3.10.2 for 4.1? and thus harvest the value in 3.10.2-build? > > > Regards, > > Ralph Boland > > -- Casey Ransberger |
In reply to this post by Ralph Boland
On Sun, 14 Mar 2010, Ralph Boland wrote:
>>>>>>>> "Ken" == Ken G Brown <[hidden email]> writes: >>> >>> Ken> You had at least two available starting points, 3.10.2 and 3.10.2-build, >>> Ken> -buiild was clearly better and available since June 28, 2009 (before >>> Ken> trunk). The fixes and additions to 3.10.2 in -build were clearly >>> Ken> documented in the info file on the ftp site, >>> Ken> Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. And >> Ken> you all are choosing the one that was inferior as a starting point. >>> >>> I think I could find at least a dozen squeak developers here who >>> would agree with me that if 3.10.2-build was a fixed point, it's >>> a bad name for a release, and if it was a moving point, it would >>> be a bad place to start the legal process. >>> >>> Had that been released as 3.10.3, or 3.11, your point would have merit. > > I agree that for 4.0 it is too late to use 3.10.2-build. > However, would it be possible to apply trunk to 3.10.2-build instead of > 3.10.2 for 4.1? and thus harvest the value in 3.10.2-build? Hardly. 3.10.2-build has MC1.5 which cannot load all the packages from the repository. AFAIK we have all but one fix from 3.10.2-build and that fix is just an enhancement of SystemVersion. Levente > > > Regards, > > Ralph Boland > > |
On 15.03.2010, at 06:06, Levente Uzonyi wrote:
> > On Sun, 14 Mar 2010, Ralph Boland wrote: >> I agree that for 4.0 it is too late to use 3.10.2-build. >> However, would it be possible to apply trunk to 3.10.2-build instead of >> 3.10.2 for 4.1? and thus harvest the value in 3.10.2-build? > > Hardly. 3.10.2-build has MC1.5 which cannot load all the packages from the repository. AFAIK we have all but one fix from 3.10.2-build and that fix is just an enhancement of SystemVersion. Since we will need to rebase trunk on 4.0 anyway, that might be a good time to upgrade MC? That is: 1) start with 4.0 image 2) load better MC (1.5 + fixes and additions necessary to make trunk updating work) 3) try updating from trunk 4) if updating breaks, add more fixes to MC 1.5, go to step 1. 5) done. - Bert - |
2010/3/15 Bert Freudenberg <[hidden email]>:
> On 15.03.2010, at 06:06, Levente Uzonyi wrote: >> >> On Sun, 14 Mar 2010, Ralph Boland wrote: >>> I agree that for 4.0 it is too late to use 3.10.2-build. >>> However, would it be possible to apply trunk to 3.10.2-build instead of >>> 3.10.2 for 4.1? and thus harvest the value in 3.10.2-build? >> >> Hardly. 3.10.2-build has MC1.5 which cannot load all the packages from the repository. AFAIK we have all but one fix from 3.10.2-build and that fix is just an enhancement of SystemVersion. > > Since we will need to rebase trunk on 4.0 anyway, that might be a good time to upgrade MC? That is: > > 1) start with 4.0 image > 2) load better MC (1.5 + fixes and additions necessary to make trunk updating work) > 3) try updating from trunk > 4) if updating breaks, add more fixes to MC 1.5, go to step 1. > 5) done. > > - Bert - > If it's doable in reasonnable time and has some technical support, why not. Since MC itself has been patched during trunk process, that also deserve some care. Nicolas |
On 15.03.2010, at 14:31, Nicolas Cellier wrote:
> > 2010/3/15 Bert Freudenberg <[hidden email]>: >> On 15.03.2010, at 06:06, Levente Uzonyi wrote: >>> >>> On Sun, 14 Mar 2010, Ralph Boland wrote: >>>> I agree that for 4.0 it is too late to use 3.10.2-build. >>>> However, would it be possible to apply trunk to 3.10.2-build instead of >>>> 3.10.2 for 4.1? and thus harvest the value in 3.10.2-build? >>> >>> Hardly. 3.10.2-build has MC1.5 which cannot load all the packages from the repository. AFAIK we have all but one fix from 3.10.2-build and that fix is just an enhancement of SystemVersion. >> >> Since we will need to rebase trunk on 4.0 anyway, that might be a good time to upgrade MC? That is: >> >> 1) start with 4.0 image >> 2) load better MC (1.5 + fixes and additions necessary to make trunk updating work) >> 3) try updating from trunk >> 4) if updating breaks, add more fixes to MC 1.5, go to step 1. >> 5) done. >> >> - Bert - >> > > If it's doable in reasonnable time and has some technical support, why not. > Since MC itself has been patched during trunk process, that also > deserve some care. > > Nicolas Indeed. And someone would have to step forward to actually Do It. Several people expressed interest in having Trunk use MC 1.5. Now is your chance! - Bert - |
Free forum by Nabble | Edit this page |