On Wed, Mar 23, 2011 at 4:45 PM, Miguel Cobá <[email protected]> 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
>
>
>
>
>

Reply via email to