[documentation] Problem With One of the Main CVS Pages

[Shai Gluskin]

Greg, Ryan, and Documentors,

After reading Ryan and Greg's responses, the solution seems obvious... the
page shouldn't make *any* assumptions or determine priorities for use-cases.
It should be verbose with sections clearly labeled.

-- this is *how* you check out HEAD and this is *why* you'd want to check
out HEAD
-- this is *how* you check out a specific version and this is *why* you'd
want to check out a specific version

Greg wrote:

> The only drawback I can think of for doing that is it will require us to
> update that page whenever a new version is released.
>

I think as long as it is clear that the text you are providing as a sample
is a variable (replace "Drupal-6-6" with the most recent stable release.").

*Point of clarification needed:*
Greg, what you wrote makes me ask a further clarification. It has been my
experience that if you specify "DRUPAL-6" you'll get HEAD for Drupal 6. In
order to get the most recent stable release of Drupal 6, you'd have to
specify like this: DRUPAL-6-6.

Since D-6 is not under active development, it is true that the differences
between the latest stable release and HEAD will be minimal. However,it is
still better to use the stable release rather than HEAD, in my opinion. My
experience has been that if I checkout "DRUPAL-6" --- the admin pages,
update status etc. will show the version as "6.7" when the latest stable
release is 6.6. I find that disconcerting. Also, I don't know how Update
Status would respond when 6.7 actually does get released.

Greg -- am I missing something here?

*Another Point of clarification needed:*
The docs page in question mentions that there might be times when you'd want
to check out a release of Drupal (presumably HEAD) for a *specific date*. It
mentions no use-case. This is my guess: you are testing a patch and the
patch command requires that it be applied to the precise version that the
patch was created against. Given the sometimes slow work of volunteers, it
can easily happen that new versions of HEAD are created before folks have
had a chance to test a patch. Instead of requiring the patch-creater to keep
rolling against a new HEAD, testers can simply patch against a precise
version of HEAD that existed in the past. *Please confirm (or reject) that
I've got the use-case correct here.*

Thanks much,

Shai

On Wed, Nov 19, 2008 at 7:04 PM, Greg Knaddison - GVS <
Greg at growingventuresolutions.com> wrote:

> On Wed, Nov 19, 2008 at 4:47 PM, Ryan Cross <drupal at ryancross.com> wrote:
> > Disagree.
>
> Disagree.
>
> >
> > it is very standard practice for people jumping into a new open source
> > project to want to see HEAD (or trunk or whatever) or for people's first
> > interest in CVS is to see "what's coming". Most people that are
> interested
> > in checking out a specific version (like a stable version) are more
> advanced
> > or experienced with CVS already. Someone's first jump into CVS is not
> going
> > to be doing so in an effort to make upgrading easier.
>
> Maybe, but this is Drupal.  The installer in Drupal7 gets completely
> broken on a pretty regular basis, and that's not a new thing - things
> like that often happen in HEAD.  I agreed with Shai's proposal.  I
> think it should primarily explain how to check out DRUPAL-6.  The only
> drawback I can think of for doing that is it will require us to update
> that page whenever a new version is released.
>
> Regards,
> Greg
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081119/75463992/attachment.htm