Esteban Lorenzano wrote:
So… instead following my advice, you people continue submitting and asking for integration things that are API changes.
As a result, instead gaining stability we are loosing it…
can you guys please be so kind and stop doing what you shouldn’t?
I will ask it again: *now* we need to bugfix the upcoming release.
Cleanups, enhancements, small additions *are not* bugfixing. And even if you are sure that it is not breaking anything, it most probably will do (for more details, take as an example the mail I will send in 5 min).
I know we all want a better Pharo. But at this moment the way to achieve it is to collaborate in testing, reporting and fixing the current version.
Thanks,
Esteban
Also time is consumed developing, reviewing and integrating
non-bug-cases, which could be tackling bugs.
Can a "Pharo4.0" milestone be added to Fogbugz? Setting something to
"Later" feels like it might get lost in the woods of old tickets
imported from the old tracker. For instance, I've recently submitted a
slice for [1] that adds two new methods and a trivial refactoring of one
other to Spec's ComposableModel (so I can't imagine it would break
anything), but in support of discipline on the feature freeze, I could
get by with making these PharoLauncher extensions for now and hold them
over to Pharo4.0.
[1]
https://pharo.fogbugz.com/f/cases/12677/subscribe-to-window-closed-event-outside-of-initialize
Indeed, it might even be worthwhile to be more heavy handed and for New
Cases replace 'Pharo3.0' with 'Pharo3.0-bugfix-only' - or maybe there is
some way to splash some heading text at the top of each page using
BugMonkey.
cheers -ben
