[Swift-devel] Next Swift release

[Allan Espinosa]

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>