[Swift-devel] swift versions
Sarah Kenny
skenny at uchicago.edu
Thu Oct 7 16:00:19 CDT 2010
sounds good.
just want to verify (sorry to beat this to death):
so, we alias the 'main guide' to 0.9 (as suggested) and any changes we make
will go to the doc in branches/1.0 which will then be the new alias for the
'main guide' once we do the release.
On Thu, Oct 7, 2010 at 3:45 PM, Justin M Wozniak <wozniak at mcs.anl.gov>wrote:
>
> Yup.
>
>
> On Thu, 7 Oct 2010, Mihael Hategan wrote:
>
> To summarize:
>>
>> There is a 1-1 mapping between branches and docs. One of the branches
>> (corresponding to the current release) gets linked from "main" (i.e.
>> main docs are the docs for the current release). So:
>>
>> branches/0.9 <-> 0.9 docs
>> banches/0.8 <-> 0.8 docs
>> trunk <-> trunk docs
>>
>> If current release is 0.9, then main docs = 0.9 docs.
>>
>> On Thu, 2010-10-07 at 15:30 -0500, Justin M Wozniak wrote:
>>
>>> I meant release branch. The valid branches could be hard-coded into the
>>> update.sh script. The main guide would be the doc associated with the
>>> current version. So right now, "main guide" would be aliased to 0.9 .
>>>
>>> On Thu, 7 Oct 2010, Sarah Kenny wrote:
>>>
>>> was thinking of what justin said, "I propose we have one web site but
>>>> multiple docs/guides directories, all accessible from the docs/index.php
>>>> page. Each of these would be associated with a branch"
>>>>
>>>> i was assuming that whatever branch(es) these were associated with, that
>>>> doc
>>>> would somehow need to make its way to a main guide that we are pointing
>>>> users to.
>>>>
>>>> ?
>>>>
>>>>
>>>> On Thu, Oct 7, 2010 at 3:17 PM, Mihael Hategan <hategan at mcs.anl.gov>
>>>> wrote:
>>>>
>>>> On Thu, 2010-10-07 at 14:55 -0500, Sarah Kenny wrote:
>>>>>
>>>>>> so, in that case the 'main user doc' would be something *like*
>>>>>> http://www.ci.uchicago.edu/swift/docs10/index.php ?
>>>>>>
>>>>>> and THAT would include the updates from all the current branches
>>>>>>
>>>>>
>>>>> define "all current branches". We have:
>>>>> 1. Release branches
>>>>> 2. Trunk
>>>>> 3. Development branches (which are transient entities and only there to
>>>>> make trunk's life easier).
>>>>>
>>>>> merged into it once we do a release?
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 7, 2010 at 2:42 PM, Mihael Hategan <hategan at mcs.anl.gov>
>>>>>> wrote:
>>>>>> On Thu, 2010-10-07 at 14:39 -0500, Sarah Kenny wrote:
>>>>>> > so, in this scenario, the changes to the doc that exist in
>>>>>> each branch
>>>>>> > are pushed to the main user doc when we do the release or am
>>>>>> i missing
>>>>>> > a step here?
>>>>>>
>>>>>>
>>>>>> That or we really have no "main doc" and instead we link from
>>>>>> every
>>>>>> release. Though I feel odd about that.
>>>>>>
>>>>>> >
>>>>>> > On Thu, Oct 7, 2010 at 2:34 PM, Mihael Hategan
>>>>>> <hategan at mcs.anl.gov>
>>>>>> > wrote:
>>>>>> >
>>>>>> > On Thu, 2010-10-07 at 14:28 -0500, Justin M Wozniak
>>>>>> wrote:
>>>>>> > > On Thu, 7 Oct 2010, Sarah Kenny wrote:
>>>>>> > >
>>>>>> > >> On Thu, Oct 7, 2010 at 1:08 PM, Mihael Hategan
>>>>>> > <hategan at mcs.anl.gov> wrote:
>>>>>> > >>
>>>>>> > >>> Right. I think 1.0/4.1.7 should go out soon.
>>>>>> > >>
>>>>>> > >> ok, so i guess we should decide what 'soon'
>>>>>> means ;) i am
>>>>>> > currently going
>>>>>> > >> thru the old bugs in bugzilla (at least trying
>>>>>> to close
>>>>>> > out things that have
>>>>>> > >> been already fixed or are no-longer applicable,
>>>>>> etc), but
>>>>>> > perhaps it would
>>>>>> > >> be good to determine if there are bigger issues
>>>>>> outside of
>>>>>> > that that still
>>>>>> > >> need to be dealt with before we can put what
>>>>>> we've got
>>>>>> > into a stable release
>>>>>> > >> and determine a time-frame...anything come to
>>>>>> mind?
>>>>>> > >>
>>>>>> > >> as far as documentation...does it make sense for
>>>>>> each
>>>>>> > branch to have a full
>>>>>> > >> copy of /ci/www/projects/swift under it which
>>>>>> can then be
>>>>>> > merged with the
>>>>>> > >> main/live copy whenever the code is merged?
>>>>>> admittedly, i
>>>>>> > know nothing about
>>>>>> > >> docbook, but from the standpoint of updating and
>>>>>> merging
>>>>>> > this seems to make
>>>>>> > >> sense to me (though feel free to suggest another
>>>>>> way :)
>>>>>> > >>
>>>>>> > >> ~sk
>>>>>> > >
>>>>>> > > I was looking at the update.sh script earlier
>>>>>> today- I
>>>>>> > propose we have one
>>>>>> > > web site but multiple docs/guides directories, all
>>>>>> > accessible from the
>>>>>> > > docs/index.php page. Each of these would be
>>>>>> associated with
>>>>>> > a branch.
>>>>>> > > So, similar to the existing "Historical" section
>>>>>> but for
>>>>>> > "future" branches
>>>>>> > > as well. That would take a small modification to
>>>>>> the
>>>>>> > update.sh script and
>>>>>> > > manual modification of the docs/index.php page for
>>>>>> each
>>>>>> > version number.
>>>>>> > >
>>>>>> > > We may also want to have the feature changes (past
>>>>>> and
>>>>>> > future version
>>>>>> > > numbers) available on that page but I think those
>>>>>> can be
>>>>>> > plain text.
>>>>>> > > These could be pulled directly from SVN as well.
>>>>>> > >
>>>>>> >
>>>>>> >
>>>>>> > I agree. I generally believe that documentation
>>>>>> should be kept
>>>>>> > in sync
>>>>>> > with releases (and I also think that the effort of
>>>>>> doing so is
>>>>>> > minimal).
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
> --
> Justin M Wozniak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20101007/ce299a54/attachment.html>
More information about the Swift-devel
mailing list