[Swift-devel] Next Swift release

Mihael Hategan hategan at mcs.anl.gov
Mon Dec 6 21:27:03 CST 2010


I like what Glen says.

Mihael

On Mon, 2010-12-06 at 16:05 -0500, Glen Hocky wrote:
> 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
>         
> 
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel





More information about the Swift-devel mailing list