[Swift-devel] Next Swift release
Mihael Hategan
hategan at mcs.anl.gov
Mon Dec 6 21:28:10 CST 2010
Ok. I also like what Justin says.
Mihael
On Mon, 2010-12-06 at 15:36 -0600, Justin M Wozniak 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>
> >
> >
>
More information about the Swift-devel
mailing list