[Swift-devel] Next Swift release

Mon Dec 6 17:45:33 CST 2010

alrighty, so looks like we should branch as soon as possible. miheal and
justin would you be ok with branching the current trunk into a release
candidate tomorrow? also, mike wilde and i were just discussing that it
would be good to know if there are any significant features available in
'stable branch 1.0' that are NOT currently in trunk so that we could include
them...any ideas on a good way to determine that?

~sk

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

> I think we need to move more toward a "release often" strategy, and I think
> a 12/20 release is a good step in that direction.  I want to stay focused on
> that target.
>
> To focus on that:
>
> - call it 0.91
> - based on trunk as of this week (i.e. as soon as we can branch)
> - doc improvements as possible
> - decide on platforms we can test by 12/20
> - test is: language tests already in test suite
> - platform tests to be added, based on "catsn" simple cat loop
>
> Mike
>
>
> ------------------------------
>
> honestly if we're shooting for the end of january on a 1.0 release i think
> it would be better to branch trunk now for testing/debugging & doc and focus
> our effort on that rather than to also have an intermediary 12/20 release.
>
> releasing branch 1.0 as a stable release in the interim *kind of* made
> sense to me since it truly is stable,ready for release and would help update
> our web site so we're not specifiying such an old version for download , but
> if we're talking about branching trunk in its current state i'd lean towards
> a 1.0 release on 1/31.
>
> ~sk
>
> On Mon, Dec 6, 2010 at 1:36 PM, Justin M Wozniak <wozniak at mcs.anl.gov>wrote:
>
>>
>> I think 0.91 makes sense.
>>
>>
>> On Mon, 6 Dec 2010, Michael Wilde wrote:
>>
>>  Im much more focused on the content than on what we call it.
>>>
>>> Im happy to call it anything except 1.0
>>>
>>> Thus 0.91 would be fine by me - to leave some headroom for more point
>>> releases if we're not ready for 1.0 at end of Jan.
>>>
>>> Do people like that better?
>>>
>>> Lets decide this asap so we can make the branch and testable RC.
>>>
>>> - Mike
>>>
>>>
>>> ----- Original Message -----
>>>
>>>> I would think 0.95 > 0.90 >> 0.10 > 0.9 if i turn off the scientist
>>>> part and turn on the software engineer part of my brain :)
>>>>
>>>> just like how GNOME is now 2.28 , 2.30 , etc.
>>>>
>>>> But i do agree this type of numbering confuses scientists who are the
>>>> main users of this software.
>>>>
>>>> -Allan
>>>>
>>>> 2010/12/6 Ioan Raicu <iraicu at cs.uchicago.edu>:
>>>>
>>>>> How about 0.91, or 0.95?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/6/2010 2:49 PM, Michael Wilde 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>> --
>>>> Allan M. Espinosa <http://amespinosa.wordpress.com>
>>>> PhD student, Computer Science
>>>> University of Chicago <http://people.cs.uchicago.edu/~aespinosa<http://people.cs.uchicago.edu/%7Eaespinosa>
>>>> >
>>>>
>>>
>>>
>>>
>> --
>> Justin M Wozniak
>>
>> _______________________________________________
>> 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/c4ffda7c/attachment.html>