re: release process (was "Shrinking alpha image")

Hi Daniel--

> If you have an operational model of how we get to where you propose
> we should be, go ahead.

	Okay.

> A few questions it should answer -
> * How do we know what the community will come up with beforehand?

	We don't need to read minds. We can just decide that features get
*scheduled* before they get included. E.g., if you come up with some
whizzy new feature during the 3.6 cycle, you can suggest it for a future
feature schedule (3.7 or later).

	Of course there will be some deviation from the ideal. For example,
critical fixes often get special dispensation (inclusion into the
current schedule instead of waiting for a future schedule). In general,
though, I think it's good to encourage planning the next several
releases. In particular, at any given time there are usually large
features (e.g., changing the format of compiled methods) that one can
imagine happening in the next major release as opposed to the next minor
release.

	I don't see a contradiction here.

> * How do we get everyone to actually test and document everything?

	If it's not tested and documented, it gets rejected.

> * How do we avoid being such pests that nobody actually wants to submit
> anything?

	By making releases that are useful, and by gently pointing to release
standards around which there is community consensus.

> ...the second and third are reasonably addressed by QA tags -if we
> stick to them and accept nothing that doesn't have them-.

	Yeah, I think that could work.


-C

--
Craig Latta
http://netjam.org/resume
[email protected]
From [email protected] Sat Mar 22 12:47:22 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 23440 invoked from network); 22 Mar 2003 12:47:22 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 22 Mar 2003 12:47:22 -0000
Received: from aSqueakSystem ([80.178.97.232]) by mxout4.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Sat,
 22 Mar 2003 14:49:29 +0200 (IST)
Date: Sat, 22 Mar 2003 14:32:54 +0300
From: [email protected]
Subject: RE: [Squeakfoundation]updating to next version after declining alpha
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5174
Content-transfer-encoding: 7BIT
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2003 12:47:23 -0000

How about this combination -
1. By default we don't put in "final updates" that will cause
compatibility problems.
2. When we put out alpha, someone can create a small SM package that
changes versions specifically from m.n to m.n+1. Installing it will
allow people to continue updating, but warn that there's a small chance
the updates will be incompatible, so save your image first.

Should solve 95% of these issues.

Daniel

Andreas Raab <[email protected]> wrote:
> Doug,
> 
> Three notes on this. First of all, the rollover message has some rather
> scary implications. It implies that you _will_ receive "test pilot" updates
> when you advance your system to alpha vs. that you _may_ receive final fixes
> if you choose the other way. I would suggest to change this towards
> something indicating that if you go into a final branch you're really
> entering a dead end versus going onto alpha you _may_ update your system to
> the next version at a point of your choosing. Note the subtle difference ;-)
> 
> Secondly, it should be pretty straightforward to flip from a final branch
> over to the next alpha - after all, all that's needed is setting the system
> version right. A simple thing that could be done is to install a "next
> version identifier" which contains the next future version a system could be
> advanced to. If you choose to, then all that happens is that you are set to
> the next update branch. This would allow people to stay with (for example)
> 3.5 until 3.6 is finalized, then switch to 3.6 (at which point the next
> future version is 3.6alpha) and update through everything (during which
> there may be other future versions such as beta and gamma). When you receive
> one of these advance messages choosing the "dead end" would just install the
> next future (perhaps this is a better way of distinguishing the streams - a
> "live" and a "dead" one; with the dead one only containing retrofitted stuff
> from the live one).
> 
> Also, concerning feeding back fixes into "final" branches I think that a
> Very Useful rule of thumb should be that any fix going into final should be
> resiliant to updating through the point at which it appears in the next
> future version (testing this is almost trivial). For 95% of the fixes this
> will be the case anyway. For the remaining 5% an explicit warning in the
> update that "installing this update/fix will remove your ability to advance
> to X.Y" might be appropriate. If the above mechanism would exist, the update
> could simply reset the next future version.
> 
> BTW, this entire thing is an issue I am quite interested in myself. With the
> rapid releases you are aiming at it's a real pain in the neck to jump
> versions. I was going to switch Croquet to 3.4 but now you're talking about
> finalizing 3.5 already so I'm going to wait for this. Unless, of course,
> there's going to be a 3.6 a month after that in which case I might wait for
> it ;-)
> 
> Cheers,
>   - Andreas
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] 
> > [mailto:[email protected]] 
> > On Behalf Of Doug Way
> > Sent: Saturday, March 22, 2003 2:51 AM
> > To: Discussing the Squeak Foundation
> > Subject: Re: [Squeakfoundation]updating to next version after 
> > declining alpha
> > 
> > 
> > 
> > On Friday, March 21, 2003, at 05:39 PM, Joshua 'Schwa' Gargus wrote:
> > 
> > > Still, I don't like the idea of 3.5 final possibly being a short
> > > dead-end branch, especially when it is not made clear to users that
> > > this is the case (a newbie would have no way of knowing that loading
> > > updates to 3.5 after the branch to 3.6 might make it impossible to
> > > later update to 3.6).  At the least, the rollover message could
> > > warn that to accept further 3.5 updates voids the guarantee that
> > > a later update to 3.5 will work fine.
> > 
> > I could improve the rollover message next time to include that.  (I 
> > assume you meant "a later update to 3.6 will work fine" above.)
> > 
> > Actually, the current message sort of implies that anyway, it 
> > says that 
> > you will only be allowed to receive final fixes for the 3.5 
> > release, if 
> > you choose not to advance to the next alpha.  Here's the 
> > 3.5beta split 
> > message:
> > 
> > "Do you wish to advance to version 3.6alpha?
> > [Yes] Your system will be marked as 3.6alpha, and you will
> > subsequently receive ''test pilot'' updates for 3.6.
> > [No] Your system will be marked as 3.5beta, allowing you
> > to receive only final fixes for the 3.5 release."
> > 
> > I could add it to something like "Your system will be marked as 
> > 3.5beta, allowing you to receive only final fixes for the 3.5 
> > release.  
> > You won't have a further opportunity to update to 3.6alpha."
> > 
> > Or, technically it should be "You may not have a further 
> > opportunity..." because in some cases, if no changes go into the beta 
> > for whatever reason, we can add another opportunity to advance when 
> > going to gamma.  This happened with 3.4beta->3.4gamma/3.5alpha.
> > 
> > Anyway, I'm not going to spend a lot of time thinking about whether 
> > there's a better solution to this, because I can't imagine one right 
> > now that's not a lot of effort. :-)  Perhaps sometime in the 
> > future if 
> > we have a generic uninstall capability.
> > 
> > - Doug Way
> > 
> > _______________________________________________
> > Squeakfoundation mailing list
> > [email protected]
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Mar 22 18:18:32 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 16916 invoked from network); 22 Mar 2003 18:18:32 -0000
Received: from mailhost2-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det3.ameritech.net) (206.141.193.106)
	by mail.theinternetone.net with SMTP; 22 Mar 2003 18:18:32 -0000
Received: from riskmetrics.com ([66.72.186.201])
	by mailhost.det3.ameritech.net
	(InterMail vM.4.01.02.17 201-229-119) with ESMTP
	<20030322181830.HMNL176.mailhost.det3.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Sat, 22 Mar 2003 13:18:30 -0500
Date: Sat, 22 Mar 2003 13:18:30 -0500
Subject: Re: [Squeakfoundation]updating to next version after declining alpha
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Doug Way <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.551)
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2003 18:18:33 -0000


On Friday, March 21, 2003, at 09:46 PM, [email protected] wrote:

> I'll second this.  I'd like to see new releases no more often than 
> once a quarter (3 months).
> Otherwise I can't keep up.

Don't worry about this... the 3.5 1-month release is an anomoly.  We're 
currently discussing having releases every 4 months after that, so that 
3.6 would come out in August.

- Doug Way


> On Friday, March 21, 2003, at 07:29  PM, Andreas Raab wrote:
>
>> BTW, this entire thing is an issue I am quite interested in myself. 
>> With the
>> rapid releases you are aiming at it's a real pain in the neck to jump
>> versions. I was going to switch Croquet to 3.4 but now you're talking 
>> about
>> finalizing 3.5 already so I'm going to wait for this. Unless, of 
>> course,
>> there's going to be a 3.6 a month after that in which case I might 
>> wait for
>> it ;-)
>>
>> Cheers,
>>   - Andreas
>>
>
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation