Smalltalk › Pharo › Pharo Smalltalk Developers

[TODO 1.2] TODO list for releasing Pharo Full 1.2

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Marcus Denker-4

[TODO 1.2] TODO list for releasing Pharo Full 1.2

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage

1. 1.2 Build is broken
2. 1.2 Config needs to load latest code from OB Repository
(or not. Maybe we should just release 1.2.1 and do that in 1.2.2)

maybe these we push to 1.2.2:

3. Omnibrowser's an extra horizontal scrollbar
4. In OB: Text in comment pane of Browser uses syntax highlighting

5. Update Hudson One-Click build files for 1.2

Marcus

--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Miguel Cobá

Re: [TODO 1.2] TODO list for releasing Pharo Full 1.2

El mié, 23-03-2011 a las 14:41 +0100, Marcus Denker escribió:
> http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage
>
> 1. 1.2 Build is broken
> 2. 1.2 Config needs to load latest code from OB Repository
> (or not. Maybe we should just release 1.2.1 and do that in 1.2.2)

No. This is the reason the build is sometimes green some times red in
hudson. The versions refered by configuration should be frozen to a
given version number forever. That is, #stable, #latestVersion,
#bleedingEdge and so should be banned from Pharo configurations when
building a release. They are ok for end users that just want a version
that works in the image they have in front of them, but not for
releases, that should be repeteable!

>
> maybe these we push to 1.2.2:
>
> 3. Omnibrowser's an extra horizontal scrollbar
> 4. In OB: Text in comment pane of Browser uses syntax highlighting
>
> 5. Update Hudson One-Click build files for 1.2
>
>
> Marcus
>
>
> --
> Marcus Denker -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>

--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

Mariano Martinez Peck

Re: [TODO 1.2] TODO list for releasing Pharo Full 1.2

On Wed, Mar 23, 2011 at 4:45 PM, Miguel Cobá <[hidden email]> wrote:

El mié, 23-03-2011 a las 14:41 +0100, Marcus Denker escribió:

> http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage
>
> 1. 1.2 Build is broken
> 2. 1.2 Config needs to load latest code from OB Repository
> (or not. Maybe we should just release 1.2.1 and do that in 1.2.2)

No. This is the reason the build is sometimes green some times red in
hudson. The versions refered by configuration should be frozen to a
given version number forever. That is, #stable, #latestVersion,
#bleedingEdge and so should be banned from Pharo configurations when
building a release. They are ok for end users that just want a version
that works in the image they have in front of them, but not for
releases, that should be repeteable!

I have already said my opinion here: http://forum.world.st/Pharo-1-2-and-test-failures-tp3337119p3338014.html

If you do what you said, you will have people agians because they need to modify ConfigurationOfXXX and ConfigurationOfPharo each time a new MONTICELLO version of a package of XXX is commited. There is no magic. You have to choose:

1) always use the latest, and every time the build may be differnet. But we don't need to update configs all the time
2) use a frozen version, and when there are new commits, modify and commits by hand all the confs

Of course, there can be much better solutions, but there is no one offering himself to do it. People do not want to even do 2) so...

>
> maybe these we push to 1.2.2:
>
> 3. Omnibrowser's an extra horizontal scrollbar
> 4. In OB: Text in comment pane of Browser uses syntax highlighting
>
> 5. Update Hudson One-Click build files for 1.2
>
>
> Marcus
>
>
> --
> Marcus Denker -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>

--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

Igor Stasenko

Re: [TODO 1.2] TODO list for releasing Pharo Full 1.2

Guys, i think you approach to the problem at wrong angle.
Pick any successful Pharo 1.2 build. Declare it as release. Milestone
passed. Done.

Nobody cares that something gets wrong after, as result of ongoing
development. That the way it goes.. Something got broken,
something got repaired.

My impression that you just stumbled over insignificant mercantile detail.
Make it perfect on next release. Lets just move on.

--
Best regards,
Igor Stasenko AKA sig.

NorbertHartl

Re: [TODO 1.2] TODO list for releasing Pharo Full 1.2

I think the broken build is good. It shows that the process of building releases is not stable. Not stable in this case means you don't have control over what is going on. Building releases with x.y.z version numbers forces you to have control over it to some extent.
I think a main point of having the configurations is not to have to check every individiual version of every package everytime. If you don't have the control and you care about release 1.2.1 is not significantly different than 1.2.2 wouldn't have to check each version of each package every time afterwards-

I would agree that this can be considered a "no show stopper" but I would be cautious to make a habit out of it.

Norbert

Am 24.03.2011 um 00:40 schrieb Igor Stasenko:

> Guys, i think you approach to the problem at wrong angle.
> Pick any successful Pharo 1.2 build. Declare it as release. Milestone
> passed. Done.
>
> Nobody cares that something gets wrong after, as result of ongoing
> development. That the way it goes.. Something got broken,
> something got repaired.
>
> My impression that you just stumbled over insignificant mercantile detail.
> Make it perfect on next release. Lets just move on.
>

Stéphane Ducasse

Re: [TODO 1.2] TODO list for releasing Pharo Full 1.2

In reply to this post by Igor Stasenko

+1

For me 1.2 is stable and robust now we should fix the process but in that case let us focus on 1.3 and start 1.3 dev

Stef

On Mar 24, 2011, at 12:40 AM, Igor Stasenko wrote: