[Swift-devel] swift versions

[Justin M Wozniak]

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