[Pharo-project] about preparing the first release
Hi guys I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you? Stef
On Sep 24, 2008, at 22:08 , Stéphane Ducasse wrote:
Hi guys
I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you?
Sounds good. We should also think about if we do a beta phase before releasing and if we will maintain the most recent released version? I think if we continue making radical changes, we need to maintain the most recent stable release, that is, to apply critical bug fixes to it. And, what numbering scheme do we use? I'd suggest the common major.minor[.maintenance] scheme starting with "1.0". The first maintenance release then would be 1.0.1 and the following release would be 1.1 etc. An increase of the major digit would only be justified when fundamental changes are introduced (like image format change). Adrian
Hi guys
I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you?
Sounds good.
We should also think about if we do a beta phase before releasing and if we will maintain the most recent released version? I think if we continue making radical changes, we need to maintain the most recent stable release, that is, to apply critical bug fixes to it.
Sure this is really important.
And, what numbering scheme do we use?
I'd suggest the common major.minor[.maintenance] scheme starting with "1.0". The first maintenance release then would be 1.0.1 and the following release would be 1.1 etc. An increase of the major digit would only be justified when fundamental changes are introduced (like image format change).
ok for me. Stef
On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I'd suggest the common major.minor[.maintenance] scheme starting with "1.0".
I would not start with "1.0" because it means this is already stable enough for anyone to rely upon. Maybe 0.1 would be more appropriate. I also like the versioning scheme of Ubuntu: 08.10 means a major release which happened in October 2008. If they want a new maintainance release, they will call it 08.10.1. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Sep 25, 2008, at 11:12 , Damien Cassou wrote:
On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I'd suggest the common major.minor[.maintenance] scheme starting with "1.0".
I would not start with "1.0" because it means this is already stable enough for anyone to rely upon.
isn't this exactly the goal of the release?! Only if the shipped version is reasonably stable the people will use it... Adrian
participants (3)
-
Adrian Lienhard -
Damien Cassou -
Stéphane Ducasse