[Swift-devel] Next Swift release

Michael Wilde wilde at mcs.anl.gov
Mon Dec 6 15:11:09 CST 2010


Speaking of which, Glen - can you be a friendly release-candidate tester for 0.10.0? 


- Mike 

----- Original Message -----


Been following along. Just a random suggestion but perhaps if you called this next release * 0.10.0* people would realize that it's zero-point-ten-point-oh as in 0.10.0> 0.9 not zero-point-one-oh as in 0.10<0.9 


-Glen 


On Mon, Dec 6, 2010 at 3:49 PM, Michael Wilde < wilde at mcs.anl.gov > wrote: 



> here's how i understand it (feel free to correct me): 
> 
> 1.0 is the most recent stable branch ready for release--it's probably 
> what most people *should* be downloading now if they want to start 
> using swift, though our web site still has the 1.5 yr old .9 listed as 
> the release download. 

Right - and thus almost no users know about or use the 1.0 branch. 
I only use trunk, as do all the users that I'm working with. 

I believe trunk should be the basis for the 12/20 release. 

I do not feel we should release test what's in any of the "stable" branches. 

Instead I feel we should "save" the 1.0 branch for when we are ready for doing a 1.0 release: say Jan 31 2011. 

I propose we create an 0.10 stable branch as the release candidate for a Dec 20 0.10, and that we use tags to mark release candidates in this branch. 


> trunk contains 'bleeding edge' code. for a 12/20 
> release we'd want to release something that does not have any new 
> features currently being added to it (just bug fixes). 

Yes - but just bug fixes over current trunk. No new features, just bug fixes from tests and any user-reported bugs. If we can make a release candidate this week, we can have users starting to test thus 0.10 RC in parallel with our testing. 


> i'm suggesting 
> that we do add *some* new doc since that won't break anything and we 
> need to do some cleanup there. 

Doc improvements for 0.10 sound good to me, but need to balance the effort required vs testing 0.10. 


> but documenation for new features 
> should go into the latest trunk doc. 

Agreed. But with "new features" defined as features beyond whats in trunk as of this moment. 


> if we want to look at releasing what's in trunk RIGHT NOW, it seems to 
> be it should be brached and go into testing mode if we want to get it 
> to a point where it's stable enough to release (?) 

Yes, I agree, per above. Lets branch it asap. 

Does tagging releae candidates on this branch seem the way to go? 


> that said, .9 vs branch 1.0 is a pretty significant upgrade...is why i 
> suggested .10 was rather confusing as a name for it. 

I took the name 0.10 from a suggestion by Ben (long ago) to deal with the fact that we may need more point-releases between 0.9 and 1.0. 

I agree that 0.10 is a *bit* confusing, but Im hoping that this release has about a 6-week lifetime from 12/20 to 1/31. 

Sound OK? 

- Mike 




> thoughts? 
> 
> ~sk 
> 
> 
> On Mon, Dec 6, 2010 at 12:01 PM, Michael Wilde < wilde at mcs.anl.gov > 
> wrote: 
> 
> 
> 
> 
> Im loosing track, but I thought trunk will become branch 0.10? 
> 
> 
> I wanted to name it based on what we're trying to say to the user 
> community: this next release I feel is still pre-1.0 quality. After 
> more doc cleanup and usability cleanup and web polishing, I feel we're 
> ready to try to make a broader announcement and call it 1.0. Im 
> thinking end of this January for that. 
> 
> 
> - Mike 
> 
> 
> 
> 
> 
> 
> 
> feel free, justin. i'm currently editing stuff that i think should go 
> into doc for the 12/20 release (e.g. describing features that exist 
> but aren't documented, etc.). 
> 
> so, branch 1.0 will become release 0.10...seems a bit confusing to 
> me...also considering the differences between 0.9 and what we're 
> releasing doesn't calling it 1.0 make sense? just a thought... 
> 
> ~sk 
> 
> 
> On Mon, Dec 6, 2010 at 7:51 AM, Justin M Wozniak < wozniak at mcs.anl.gov 
> > wrote: 
> 
> 
> 
> Sounds great- I was actually thinking about setting up the 
> branch-specific docs later this week, do you already have a start on 
> that? 
> 
> 
> 
> 
> On Mon, 6 Dec 2010, Sarah Kenny wrote: 
> 
> 
> 
> so, my expectation for the release, as we've discussed somewhat on the 
> list 
> already, is to put out swift 1.0 on 12/20 which, as i see it, involves 
> primarily editing of the documentation/web content more so than 
> anything 
> else since all new code (and documentation associated with the new 
> code) 
> going into trunk is expected to be in the 1.1. release--which 
> hopefully we 
> can have out in the next few months. i'm also assuming we're sticking 
> with 
> the plan to allow each release to have its own doc version along with 
> the 
> code. 
> 
> let me know if anyone thinks there are other things that can/should go 
> into 
> the 12/20 release. 
> 
> ~sk 
> 
> On Tue, Nov 23, 2010 at 2:10 PM, Michael Wilde < wilde at mcs.anl.gov > 
> wrote: 
> 
> 
> 
> All, 
> 
> Sarah is going to take the lead in producing the next Swift release, 
> and 
> will propose a release definition and plan. We want to have the 
> release done 
> by Dec 20. 
> 
> - Mike 
> 
> _______________________________________________ 
> Swift-devel mailing list 
> Swift-devel at ci.uchicago.edu 
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel 
> 
> 
> 
> -- 
> Justin M Wozniak 
> 
> 
> 
> 
> 
> -- 
> Michael Wilde 
> Computation Institute, University of Chicago 
> Mathematics and Computer Science Division 
> Argonne National Laboratory 

-- 
Michael Wilde 
Computation Institute, University of Chicago 
Mathematics and Computer Science Division 
Argonne National Laboratory 

_______________________________________________ 
Swift-devel mailing list 
Swift-devel at ci.uchicago.edu 
http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel 




-- 
Michael Wilde 
Computation Institute, University of Chicago 
Mathematics and Computer Science Division 
Argonne National Laboratory 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20101206/16757417/attachment.html>


More information about the Swift-devel mailing list