[Pharo-project] [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.
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
On Wed, Mar 23, 2011 at 4:45 PM, Miguel Cobá <miguel.coba@gmail.com> 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
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.
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.
+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:
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.
participants (6)
-
Igor Stasenko -
Marcus Denker -
Mariano Martinez Peck -
Miguel Cobá -
Norbert Hartl -
Stéphane Ducasse