[Swift-devel] Next Swift release

Mon Dec 6 15:43:46 CST 2010

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20101206/4dbb13e8/attachment.html>