Trunk image size

On 12/11/09 11:55 AM, "Bert Freudenberg" <[hidden email]> wrote:

> The sum of version numbers in the very first Trunk config map (update.ar-1)
> was 2518.
>
> 3.10.2 had as highest update 7179.
>
> So it would make sense to use 7179 - 2518 + 1 as a base.

Ok, what if stop here, modify
unloadSomeMore
#( 'SMLoader' 'SMBase' 'ScriptLoader' 'Universes' 'Installer' )
        do: [:ea | (MCPackage named: ea) unload].
        self fixObsoleteReferences

And do ReleaseBuilderFor3dot11 new
And nominate Squeak3.11, declare Squeak 3.10.2 closed.
Reading all last days mails , seems we soon could go wild and have a really
different pet
>
> New update number would be sum of packet version numbers plus 4662.
>
> I updated my package in the inbox.
>
> - Bert -

Ok, no problem

I could do the hard work, submit to Board for quality check.
Add doing all boring test in Mac, Windows XP and Linuz ASAP .

We have a deal ?

Edgar

On 11.12.2009, at 14:41, K. K. Subramaniam wrote:
Independent of how to assign version numbers ...

IMHO instead of branching for release we should do a feature freeze and code freeze, maybe for 2 weeks, call the result a release, and then continue the happy hacking. Otherwise the burden of releasing again falls onto too few people. We should *all* be working towards a release together. The actual releasing would take nothing more than packaging and uploading.

- Bert -

2009/12/11 Bert Freudenberg <[hidden email]>:
> IMHO instead of branching for release we should do a feature freeze and code freeze, maybe for 2
> weeks, call the result a release,

+1

my 2 c.

How about making a monthly release?
- package stuff,
- remove #( 'SMLoader' 'SMBase' 'ScriptLoader' 'Universes' 'Installer' ) blabla

- update the wellcome message
- give a credit to everyone , participated in monthly delta (authors
of updates for last month)
- put image on server , make it publicly available.

- a version number format for those images will be  Squeak
3.x.y-<update number>-mm-yyyy
(don't need days, since it monthly)

As for the major releases, we can decide it in process. Or simply take
already existing monthly image (micro release)
and declare it to be the next minor release.

Edgar, would you be willing to take responsibility for doing that
(once per month)?

Since you are experienced in preparing image for release, it would be
good if we could have an established process and a stuart who
publishing images regularily.
Before that, this was done by Damien Cassou, but it looks like he's
lost interest in making monthly releases (or maybe not?).
And i found it quite helpfull to be able to quickly download most
recent image(s), in case of need , as well as others, i hope.


2009/12/11 Germán Arduino <[hidden email]>:
> 2009/12/11 Bert Freudenberg <[hidden email]>:
>> IMHO instead of branching for release we should do a feature freeze and code freeze, maybe for 2
>> weeks, call the result a release,
>
> +1
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 11-Dec-09, at 5:41 AM, K. K. Subramaniam wrote:

Yuck. I know Linus does it that way, but still. Yuck.

Colin

Bert Freudenberg wrote:
> My proposal is in the inbox (update trunk first).
>
> Name: System-bf.193
> Author: bf
> Time: 11 December 2009, 12:38:45.256 pm
> UUID: 4609ebf3-3481-4f3a-99d6-1c4e9534d2fa
> Ancestors: System-nice.192
>
> - after updating, set the current system version to the latest date found in all system packages. Also set the highest update number to the sum of version numbers.

I like it. For the base number, how about we add a stub package that
identifies the base number? Right now this would be
Squeak-Version-foobar.4662.mcz.

This would allow us to deal with package removals, i.e., when we remove
a package we manually bump that version by the version of the removed
package which also allows us to add a comment along the lines of
"removed package foo bar; bumped base version by X". Without something
like this we're risking to run backwards in versions during removals.


Cheers,
   - Andreas

On 12/11/09 1:17 PM, "Igor Stasenko" <[hidden email]> wrote:
Yes to all.
On weekend we could meet on Skype (edgardec) or IRC for fine details

By the way, I have this
http://ftp.squeak.org/various_images/FunSqueak/FunTrunk.20091204.zip

Take a look and say what you think

Edgar

On Friday 11 December 2009 08:04:14 pm Bert Freudenberg wrote:
> IMHO instead of branching for release we should do a feature freeze and
>  code freeze, maybe for 2 weeks, call the result a release, and then
>  continue the happy hacking. Otherwise the burden of releasing again falls
>  onto too few people. We should all be working towards a release together.
>  The actual releasing would take nothing more than packaging and uploading.
Sure.  We could have a short 'cool down' period when the  trunk is frozen. . A
release is much more than packaging and uploading. People will need time to  
cleanup image, take screenshots and screencasts for documentation, update
documents and websites, post announcements, blogs etc.

Just so that the pace doesn't slacken, The Freeze can be kept short (say no
more than two weeks) and well-spaced (say no more than four freezes in a
year).

Now back to the topic of image versioning :-).

Subbu

On 11.12.2009, at 18:14, Andreas Raab wrote:
That seems almost a bit too clever ;-)

OTOH it does beat a magic base number in the code. Sounds good.

- Bert -

On 12.12.2009, at 01:57, Bert Freudenberg wrote:
I took out the offset and pushed this to Trunk as System-bf.195. Did not put a stub package in the config map yet.

- Bert -

Edgar J. De Cleene wrote:
> Ok, what if stop here, modify
> unloadSomeMore
> #( 'SMLoader' 'SMBase' 'ScriptLoader' 'Universes' 'Installer' )
>         do: [:ea | (MCPackage named: ea) unload].
>         self fixObsoleteReferences

Before we start unloading packages we really need to have a little chat
about how to deal with "external" packages and what the default
configuration of Squeak should be. (I owe the board a post on this topic
and I think today is the day where I'm doing that, so stay tuned)

> And nominate Squeak3.11, declare Squeak 3.10.2 closed.

3.10.2 *is* closed for all intents and purposes. Don't confuse the
naming of the current trunk image. It is not meant to imply that it will
be the basis for a 3.10.3 release. It's only meant to imply that this
was the take-off point. (and like I said I'll be happy to switch to 3.11
name in the next build)

> I could do the hard work, submit to Board for quality check.
> Add doing all boring test in Mac, Windows XP and Linuz ASAP .
>
> We have a deal ?

Sorry, I'm not sure what work you are referring to. Can you repeat the
list of steps you're proposing?

Cheers,
   - Andreas

On 12/12/09 2:43 AM, "Andreas Raab" <[hidden email]> wrote:

No news , until now
>
>> And nominate Squeak3.11, declare Squeak 3.10.2 closed.
>
> 3.10.2 *is* closed for all intents and purposes. Don't confuse the
> naming of the current trunk image. It is not meant to imply that it will
> be the basis for a 3.10.3 release. It's only meant to imply that this
> was the take-off point. (and like I said I'll be happy to switch to 3.11
> name in the next build)
>
c
>>
>> We have a deal ?
>
> Sorry, I'm not sure what work you are referring to. Can you repeat the
> list of steps you're proposing?
>
> Cheers,
>    - Andreas
>
First point of agree (or not)

The boundary between 3.10 and next image, let me name 3.11, should be when
in the Trunk process we introduce Closures.

It's clear a Closures images don't could load old .pr , as example.
Need a  different VM.

So, we should
Use old beloved sftp://[hidden email]/home/updates/
Put here some .cs for start the Trunk process
I send some a few days ago.
I beg you review, approve or change to your will
Put the .cs in the folder
When process  try to load Closures, this should be the end of 3.10.2 and the
start of 3.11
Here should be
nnnnAdvanceToThreeDotTenAlpha

Here I run all boring test in Mac, Windows XP and Linuz ASAP .
Send the ugly true to list.
Ugly as different OS give me different green, yellow , blue
I think this upset Ralph...

Waiting news...

Edgar

Edgar