<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Speaking of which, Glen - can you be a friendly release-candidate tester for 0.10.0?<div><br></div><div>- Mike<br><br><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;">Been following along. Just a random suggestion but perhaps if you called this next release *<b>0.10.0* </b>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<div>
<br></div><div>-Glen<br><br><div class="gmail_quote">On Mon, Dec 6, 2010 at 3:49 PM, Michael Wilde <span dir="ltr"><<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> here's how i understand it (feel free to correct me):<br>
><br>
> 1.0 is the most recent stable branch ready for release--it's probably<br>
> what most people *should* be downloading now if they want to start<br>
> using swift, though our web site still has the 1.5 yr old .9 listed as<br>
> the release download.<br>
<br>
</div>Right - and thus almost no users know about or use the 1.0 branch.<br>
I only use trunk, as do all the users that I'm working with.<br>
<br>
I believe trunk should be the basis for the 12/20 release.<br>
<br>
I do not feel we should release test what's in any of the "stable" branches.<br>
<br>
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.<br>
<br>
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.<br>
<div class="im"><br>
> trunk contains 'bleeding edge' code. for a 12/20<br>
> release we'd want to release something that does not have any new<br>
> features currently being added to it (just bug fixes).<br>
<br>
</div>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.<br>
<div class="im"><br>
> i'm suggesting<br>
> that we do add *some* new doc since that won't break anything and we<br>
> need to do some cleanup there.<br>
<br>
</div>Doc improvements for 0.10 sound good to me, but need to balance the effort required vs testing 0.10.<br>
<div class="im"><br>
> but documenation for new features<br>
> should go into the latest trunk doc.<br>
<br>
</div>Agreed. But with "new features" defined as features beyond whats in trunk as of this moment.<br>
<div class="im"><br>
> if we want to look at releasing what's in trunk RIGHT NOW, it seems to<br>
> be it should be brached and go into testing mode if we want to get it<br>
> to a point where it's stable enough to release (?)<br>
<br>
</div>Yes, I agree, per above. Lets branch it asap.<br>
<br>
Does tagging releae candidates on this branch seem the way to go?<br>
<div class="im"><br>
> that said, .9 vs branch 1.0 is a pretty significant upgrade...is why i<br>
> suggested .10 was rather confusing as a name for it.<br>
<br>
</div>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.<br>
<br>
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.<br>
<br>
Sound OK?<br>
<br>
- Mike<br>
<div><div></div><div class="h5"><br>
> thoughts?<br>
><br>
> ~sk<br>
><br>
><br>
> On Mon, Dec 6, 2010 at 12:01 PM, Michael Wilde < <a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
> Im loosing track, but I thought trunk will become branch 0.10?<br>
><br>
><br>
> I wanted to name it based on what we're trying to say to the user<br>
> community: this next release I feel is still pre-1.0 quality. After<br>
> more doc cleanup and usability cleanup and web polishing, I feel we're<br>
> ready to try to make a broader announcement and call it 1.0. Im<br>
> thinking end of this January for that.<br>
><br>
><br>
> - Mike<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> feel free, justin. i'm currently editing stuff that i think should go<br>
> into doc for the 12/20 release (e.g. describing features that exist<br>
> but aren't documented, etc.).<br>
><br>
> so, branch 1.0 will become release 0.10...seems a bit confusing to<br>
> me...also considering the differences between 0.9 and what we're<br>
> releasing doesn't calling it 1.0 make sense? just a thought...<br>
><br>
> ~sk<br>
><br>
><br>
> On Mon, Dec 6, 2010 at 7:51 AM, Justin M Wozniak < <a href="mailto:wozniak@mcs.anl.gov" target="_blank">wozniak@mcs.anl.gov</a><br>
> > wrote:<br>
><br>
><br>
><br>
> Sounds great- I was actually thinking about setting up the<br>
> branch-specific docs later this week, do you already have a start on<br>
> that?<br>
><br>
><br>
><br>
><br>
> On Mon, 6 Dec 2010, Sarah Kenny wrote:<br>
><br>
><br>
><br>
> so, my expectation for the release, as we've discussed somewhat on the<br>
> list<br>
> already, is to put out swift 1.0 on 12/20 which, as i see it, involves<br>
> primarily editing of the documentation/web content more so than<br>
> anything<br>
> else since all new code (and documentation associated with the new<br>
> code)<br>
> going into trunk is expected to be in the 1.1. release--which<br>
> hopefully we<br>
> can have out in the next few months. i'm also assuming we're sticking<br>
> with<br>
> the plan to allow each release to have its own doc version along with<br>
> the<br>
> code.<br>
><br>
> let me know if anyone thinks there are other things that can/should go<br>
> into<br>
> the 12/20 release.<br>
><br>
> ~sk<br>
><br>
> On Tue, Nov 23, 2010 at 2:10 PM, Michael Wilde < <a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> All,<br>
><br>
> Sarah is going to take the lead in producing the next Swift release,<br>
> and<br>
> will propose a release definition and plan. We want to have the<br>
> release done<br>
> by Dec 20.<br>
><br>
> - Mike<br>
><br>
> _______________________________________________<br>
> Swift-devel mailing list<br>
> <a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
> <a href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel" target="_blank">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a><br>
><br>
><br>
><br>
> --<br>
> Justin M Wozniak<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Michael Wilde<br>
> Computation Institute, University of Chicago<br>
> Mathematics and Computer Science Division<br>
> Argonne National Laboratory<br>
<br>
--<br>
Michael Wilde<br>
Computation Institute, University of Chicago<br>
Mathematics and Computer Science Division<br>
Argonne National Laboratory<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
<a href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel" target="_blank">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br></div>
</blockquote><br><span><br><br>-- <br><span name="x"></span>Michael Wilde<br>Computation Institute, University of Chicago<br>Mathematics and Computer Science Division<br>Argonne National Laboratory<br><span name="x"></span><br></span></div></div></body></html>