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