About the new release process
Locked
 
|
Hi folks,
Now that Pharo 1.4 is out, I want to talk a bit about our new release process. As you know (if you read the Pharo vision document [1]), we are switching our release process into a more predictable one: time based, not feature based. We are adopting an "Ubuntu like" model, with one mayor release per year, and two bug fix releases at month 4 and month 8. So, the next releases will have this numbering: 2.0 big release (we hope to have it in january or february), 2.4 in april and 2.8 in august (all 2013, if Mayans were wrong and we are still alive). During this year we'll also release bugfix versions of Pharo 1.4. Each major version we want to improve the system in a lot of different ways. These are examples of what we want to achieve during 2.0 development: -Improve our release process. This is not just by being more predictable, but also about improving the current process technically. For instance, we are going to switch our release building to metacello configurations, starting with a minimal image. That means: you can take a minimal image and modify a metacello pharoconfig to build the image that you want (on your own responsibility). – We are going to adopt Opal as new compiler (this will allow us to improve a lot in that area, also to fix important bugs now living in the debugger). – Replace old SystemChangeNotification with a new announcement based system. – use Fuel as standard serialization tool (remove SmartRefStream). – remove old File System (use new based on Filesystem). – remove old HTTP (use Zinc instead). – remove old categorizer (Use RPackage instead). – remove old browser (Use nautilus instead). – remove old basic tools (use Spec to replace them). – clean up URL/URI mess (replace with some coherent unique API). In summary, it is: a) replacing old subsystems for something better. b) add new features, which is long-awaited by people. Most of your projects will not notice the changes, but some might do. In that cases, we will not break backward compatibility just because we want, but there are reasons of improvement. Also, we will follow the deprecation policy we have followed so far (whenever is possible). We want to invent the future, one step at a time. Thanks, Esteban [1] http://www.pharo-project.org/download/pictures/be/j32hajf3kjdbsebqo0a9zc5tk8ekxt/pharovision.pdf |
|
|
Gracias por el update Esteban!
|
Re: About the new release process
|
Administrator
|
In reply to this post by EstebanLM
This is exciting because as soon as a version is released, everyone starts pounding on it and inevitably finding bugs. It will be nice to have those fixes go into the current version instead of instantly starting to focus on the next major version months or a year away. I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How do we get fixes into the 1.4 bug release versions? If we make a slice off the 1.4 package, there may be many conflicts merging into 2.0, but if we merge in the future version, there will be many 2.0-only changes that have nothing to do with the fix, won't there? What's the protocol? And now that we're time-based, what's the date for the first bug fix release?
Cheers,
Sean |
|
|
Sean P. DeNigris wrote:
> EstebanLM wrote > >> our new release process... >> two bug fix releases at month 4 and month 8... >> During this year we'll also release bugfix versions of Pharo 1.4. >> >> > > This is exciting because as soon as a version is released, everyone starts > pounding on it and inevitably finding bugs. It will be nice to have those > fixes go into the current version instead of instantly starting to focus on > the next major version months or a year away. > > I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How > do we get fixes into the 1.4 bug release versions? If we make a slice off > the 1.4 package, there may be many conflicts merging into 2.0, but if we > merge in the future version, there will be many 2.0-only changes that have > nothing to do with the fix, won't there? What's the protocol? And now that > we're time-based, what's the date for the first bug fix release? > > I have been considering asking similar questions for a while. First, can someone confirm and clarify my understanding of the purpose of the standard repositories... * Pharo14 - Read Only. I see five admins who presumably are the only integrators who can commit to the repository. I assume that at the time Pharo 1.4 was released, the latest versions in this repository exactly matched loaded into the released image. I assume this is now low traffic, but browsing this repository I see some packages have updates. Are these the ones that will form the basis of a Pharo 1.4.1 maintenance release? * PharoInbox - Read/Write. Anyone can submit packages here to await review by testers and integrators. * PharoTreatedInbox - Read Only. Squeaksource says "Repository for packages from the inbox that are either released or reject by the release team" but I am not clear on whether "released" means items accepted into the mainline Pharo14 repository are copied to PharoTreatedInbox as well as going to the Pharo14 repository. * Pharo20 - Read Only. Active HEAD of Pharo development. What I am not clear on is how the integrators know whether a submission to PharoInbox is based off Pharo 1.4 or 2.0. From previous discussions it seems a possibility that due to limited resources a community submission to fix something in 1.4 might just be consumed into the mainline 2.0 and not backported to 1.4. Not withstanding that I understand and support the desire to push forward as fast as possible, as a business user trying to stabilize a deployed product this would be annoying. Note that I am referring here to user community contributions and not how mainline developers choose which version in which to attack ticketed issues. So then, an uncertain proposal... to create a Pharo14MaintInbox repository for contributions submitted from within a Pharo1.4 image. Optionally, any package accepted from Pharo14MaintInbox into Pharo14 could incrementally copied at that time into the mainline 2.0 PharoInbox, so as not to lose any fixes that might carry over to mainline 2.0. Alternatively, this might be done in one go when a tested 1.4.1 maintenance version is released. cheers -ben |
|
|
In reply to this post by Sean P. DeNigris
Hi,
On May 14, 2012, at 8:45 PM, Sean P. DeNigris wrote: > > EstebanLM wrote >> >> our new release process... >> two bug fix releases at month 4 and month 8... >> During this year we'll also release bugfix versions of Pharo 1.4. >> > > This is exciting because as soon as a version is released, everyone starts > pounding on it and inevitably finding bugs. It will be nice to have those > fixes go into the current version instead of instantly starting to focus on > the next major version months or a year away. yep... that's the idea... :) > I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How > do we get fixes into the 1.4 bug release versions? If we make a slice off > the 1.4 package, there may be many conflicts merging into 2.0, but if we > merge in the future version, there will be many 2.0-only changes that have > nothing to do with the fix, won't there? What's the protocol? And now that > we're time-based, what's the date for the first bug fix release? relevant issues for 1.4 are tagged now 2.0/1.4... some others just 1.4 (not many). What we considered non-relevant were re-tagged just 2.0... maybe we made a mistake in our review, but we are willing to retag them if someone has other feelings :) now... the slices can be applied in both versions or be version specific... the bugtracker keeps the information needed to the integration. times, times... we still didn't thought on times for versions release for 1.4 because we are still adjusting all to the process... but I think some time on july is good for first 1.4 release and maybe october for lastest... in any case, we are doing regular 1.4 integrations (weekly), that incorporates some bugfixes. best, Esteban |
|
|
In reply to this post by Ben Coman
Hi,
I don't understand completely your question... PharoXX repositories are for integrated stuff (by version) and just integrators can access there. PharoInbox is the place where stuff who need to be integrated goes... always tracked by an issue in the issue tracker. So, we can know if it belongs to 1.4 or 2.0 just because we have more information than just the packages commited. Ideally, if you want to fix something, you need to do it, then create a slice, commit it to inbox, then announce in bugtracker "FixReviewNeeded", then we review and if everything is ok, we integrate it :) (In fact, we are not going to integrate anything that is absent from tracker, because otherwise it is going to be really hard to see) best, Esteban On May 15, 2012, at 5:45 PM, Ben Coman wrote: > Sean P. DeNigris wrote: >> EstebanLM wrote >> >>> our new release process... >>> two bug fix releases at month 4 and month 8... During this year we'll also release bugfix versions of Pharo 1.4. >>> >> >> This is exciting because as soon as a version is released, everyone starts >> pounding on it and inevitably finding bugs. It will be nice to have those >> fixes go into the current version instead of instantly starting to focus on >> the next major version months or a year away. >> >> I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How >> do we get fixes into the 1.4 bug release versions? If we make a slice off >> the 1.4 package, there may be many conflicts merging into 2.0, but if we >> merge in the future version, there will be many 2.0-only changes that have >> nothing to do with the fix, won't there? What's the protocol? And now that >> we're time-based, what's the date for the first bug fix release? >> >> > > I have been considering asking similar questions for a while. First, can someone confirm and clarify my understanding of the purpose of the standard repositories... > > * Pharo14 - Read Only. I see five admins who presumably are the only integrators who can commit to the repository. I assume that at the time Pharo 1.4 was released, the latest versions in this repository exactly matched loaded into the released image. I assume this is now low traffic, but browsing this repository I see some packages have updates. Are these the ones that will form the basis of a Pharo 1.4.1 maintenance release? > > * PharoInbox - Read/Write. Anyone can submit packages here to await review by testers and integrators. > * PharoTreatedInbox - Read Only. Squeaksource says "Repository for packages from the inbox that are either released or reject by the release team" but I am not clear on whether "released" means items accepted into the mainline Pharo14 repository are copied to PharoTreatedInbox as well as going to the Pharo14 repository. > > * Pharo20 - Read Only. Active HEAD of Pharo development. > > What I am not clear on is how the integrators know whether a submission to PharoInbox is based off Pharo 1.4 or 2.0. From previous discussions it seems a possibility that due to limited resources a community submission to fix something in 1.4 might just be consumed into the mainline 2.0 and not backported to 1.4. Not withstanding that I understand and support the desire to push forward as fast as possible, as a business user trying to stabilize a deployed product this would be annoying. Note that I am referring here to user community contributions and not how mainline developers choose which version in which to attack ticketed issues. > > So then, an uncertain proposal... to create a Pharo14MaintInbox repository for contributions submitted from within a Pharo1.4 image. Optionally, any package accepted from Pharo14MaintInbox into Pharo14 could incrementally copied at that time into the mainline 2.0 PharoInbox, so as not to lose any fixes that might carry over to mainline 2.0. Alternatively, this might be done in one go when a tested 1.4.1 maintenance version is released. > > cheers -ben > > > > > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |