Keep documentation for previous versions when updating it to reflect new behaviour and features

22 messages Options
Embed this post
Permalink
1 2
Israel Saeta Pérez () Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
Hello list,

When updating docs to reflect new features and behaviour introduced in
last Plone versions, keep in mind that we must keep the info about how
it worked in previous versions and indicate clearly when a feature is
new in e.g. Plone 3.3.

If I'm not wrong, Plone 2.5 is still supported so anything from 2.5 to
3.x should be kept.

Thanks!

-- israel

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez
Hanno Schlichting-3 () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
Israel Saeta Pérez wrote:
> If I'm not wrong, Plone 2.5 is still supported so anything from 2.5 to
> 3.x should be kept.

/me looks at Steve

I haven't seen any final official stance at this after the Board meeting
on January 8, 2009:

Follow up on Version Support Policy

Steve will prominently post policy arrived at in PF membership discussion


To my best knowledge the version policy I proposed met the boards favor,
which means at this point Plone 3.2 is the only supported release.
Support for Plone 2.5 of any kind has ended with the release of Plone
3.1 about a year ago.

Hanno


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
On Sat, Apr 18, 2009 at 5:40 PM, Hanno Schlichting <[hidden email]> wrote:

> Israel Saeta Pérez wrote:
>> If I'm not wrong, Plone 2.5 is still supported so anything from 2.5 to
>> 3.x should be kept.
>
> /me looks at Steve
>
> I haven't seen any final official stance at this after the Board meeting
> on January 8, 2009:
>
> Follow up on Version Support Policy
>
> Steve will prominently post policy arrived at in PF membership discussion
>
>
> To my best knowledge the version policy I proposed met the boards favor,
> which means at this point Plone 3.2 is the only supported release.
> Support for Plone 2.5 of any kind has ended with the release of Plone
> 3.1 about a year ago.

Does that mean that there won't be security patches for Plone<3.2?
What does supported mean in this context? Just documentation support?

-- israel

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez
Dylan Jay-4 () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink

On 19/04/2009, at 2:01 AM, Israel Saeta Pérez wrote:

> On Sat, Apr 18, 2009 at 5:40 PM, Hanno Schlichting <[hidden email]
> > wrote:
>> Israel Saeta Pérez wrote:
>>> If I'm not wrong, Plone 2.5 is still supported so anything from  
>>> 2.5 to
>>> 3.x should be kept.
>>
>> /me looks at Steve
>>
>> I haven't seen any final official stance at this after the Board  
>> meeting
>> on January 8, 2009:
>>
>> Follow up on Version Support Policy
>>
>> Steve will prominently post policy arrived at in PF membership  
>> discussion
>>
>>
>> To my best knowledge the version policy I proposed met the boards  
>> favor,
>> which means at this point Plone 3.2 is the only supported release.
>> Support for Plone 2.5 of any kind has ended with the release of Plone
>> 3.1 about a year ago.
>
> Does that mean that there won't be security patches for Plone<3.2?
> What does supported mean in this context? Just documentation support?

Not sure about policies etc in my opinion one the least confusing ways  
of doing it is to keep copies of official manuals in folders marked  
with the version number... like python does
http://www.python.org/doc/2.4.4/lib/lib.html
Then the documentation reader *always* knows at a glance they are/
aren't reading the documentation for the version they want.
Just my $0.02AUD
Does that work with what the board and/or documentation direction is?



------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Raphael Ritz () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Hanno Schlichting-3
Hanno Schlichting wrote:

[..]

> To my best knowledge the version policy I proposed met the boards favor,
> which means at this point Plone 3.2 is the only supported release.
> Support for Plone 2.5 of any kind has ended with the release of Plone
> 3.1 about a year ago.

While I think that's correct I'd prefer us to be pragmatic
here. From what I know there are still many sites out there
that are on Plone 2.5.x (and some even older than that).

When it comes to documentation I would not purposefully remove
the old stuff per default but simply mark it as such, e.g., like
Dylan suggested. I don't see any harm in keeping old documentation
around as long as we do it in such a way that people don't get
confused.

So for me, the question boils down to: how to best avoid potential
confusion without simply removing the old stuff?

Just my 20 Öre,

        Raphael


>
> Hanno
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Plone-docs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-docs


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Graham Perrin () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Dylan Jay-4
Hanno Schlichting wrote:

> Israel Saeta Pérez wrote:
>
>> If I'm not wrong, Plone 2.5 is still supported so anything from
>> 2.5 to 3.x should be kept.
>
> … To my best knowledge the version policy I proposed met the
> boards favor, which means at this point Plone 3.2 is the only
> supported release. Support for Plone 2.5 of any kind has ended
> with the release of Plone 3.1 about a year ago.

There was discussion in December 2008 <http://n2.nabble.com/-tp1680203p1680203.html> (I missed that, sorry) but the story that I have been told, on various occasions, is that 2.5.x will remain supported until 4.0 is released.

The announcement re: 2.1 coincided with the release of 3.0, and we gained the reassurance that:

>>> Plone Team offers security fixes and community support for
>>> two major releases

<http://n2.nabble.com/-tp362555p362555.html>

IMHO it would be wrong to change a support policy mid-term, especially when there is less than 100% widespread community appreciation of the benefits of buildout etc..

On 19 Apr 2009, at 08:43, Raphael Ritz wrote:

> From what I know there are still many sites out there that are on
> Plone 2.5.x

My recollection from the Zope/Plone day in London, February 2008, was that the *majority* of those present continued to run 2.x, with no imminent plan to upgrade to 3. There were degrees of "If it ain't broke, don't fix it", I also sensed that people had invested greatly in a particular major version.

Dylan Jay wrote:

> … keep copies of official manuals in folders marked with the
> version number... like python does
> http://www.python.org/doc/2.4.4/lib/lib.html
> Then the documentation reader *always* knows at a glance they are/
> aren't reading the documentation for the version they want.

+1

If we're thinking of *creating* folder hierarchies, it may be good to gain confirmation from someone in Plone Deco <http://groups.google.com/group/plone-deco> that an information architecture currently envisaged will be of continuing value in a Plone 4 environment.

Regards
Graham
Israel Saeta Pérez () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Raphael Ritz
On Sun, Apr 19, 2009 at 9:43 AM, Raphael Ritz wrote:
> When it comes to documentation I would not purposefully remove
> the old stuff per default but simply mark it as such, e.g., like
> Dylan suggested. I don't see any harm in keeping old documentation
> around as long as we do it in such a way that people don't get
> confused.

I definitely agree with keeping documentation for older versions.

> So for me, the question boils down to: how to best avoid potential
> confusion without simply removing the old stuff?

The "applies to" (archetypes) field of the PHC content-types is
exactly for that. Some time ago somebody removed the Plone 3.x choices
for this field and left only Plone 2.5, Plone 3.3. The good part is
that this frees us from having to bump the "applies to" field of every
doc that doesn't need changes for the upcoming version, but on the
other hand it bans us from fine-specifying the version like in the
docs only valid for 3.3.

I'd prefer to keep it as is now, since the aren't so many changes
between some version of Plone 3 and the following one, and having to
"duplicate" all docs when only a paragraph is added to some docs isn't
very efficient IMO. A more pragmatic approach is specifying that
something is only valid since Plone X.Y next to that paragraph, and
that's why we are doing for now. A bit more confusing, I must agree,
but more pragmatic too.

That policy could change when we have less docs in the "official/core"
doc section to update. Time and experience will guide us. :-)

-- israel

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez
Dylan Jay-4 () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink

On 19/04/2009, at 7:23 PM, Israel Saeta Pérez wrote:

> I'd prefer to keep it as is now, since the aren't so many changes
> between some version of Plone 3 and the following one, and having to
> "duplicate" all docs when only a paragraph is added to some docs isn't
> very efficient IMO. A more pragmatic approach is specifying that

not very efficient in terms of diskspace or time or something else?


> something is only valid since Plone X.Y next to that paragraph, and
> that's why we are doing for now. A bit more confusing, I must agree,
> but more pragmatic too.

so you're reading along and constantly have to monitor the version  
number next to each paragraph to find out if the paragraph applies to  
the one and only one version you are interested in?



------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Hanno Schlichting-3 () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Raphael Ritz
Raphael Ritz wrote:

> Hanno Schlichting wrote:
>
> [..]
>
>> To my best knowledge the version policy I proposed met the boards favor,
>> which means at this point Plone 3.2 is the only supported release.
>> Support for Plone 2.5 of any kind has ended with the release of Plone
>> 3.1 about a year ago.
>
> While I think that's correct I'd prefer us to be pragmatic
> here. From what I know there are still many sites out there
> that are on Plone 2.5.x (and some even older than that).
>
> When it comes to documentation I would not purposefully remove
> the old stuff per default but simply mark it as such, e.g., like
> Dylan suggested. I don't see any harm in keeping old documentation
> around as long as we do it in such a way that people don't get
> confused.
>
> So for me, the question boils down to: how to best avoid potential
> confusion without simply removing the old stuff?

+1

2.5 is not supported anymore in terms of maintenance updates of the
codebase (2.5.5 was released in Dec 2007).

If the documentation team has the resources to maintain the
documentation for multiple versions, that is a decision the team ought
to do.

Hanno


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
JoAnna Springsteen () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
When someone creates a doc on plone.org, there is a place to select
which version of Plone this doc applies to.
I believe Veda and SteveM have plans of doing a reorganization of how
information is presented on the Documentation landing page. Because we
already capture this data, all we have to do is clearly link to it.

As for what we keep...We still have docs that support the 2.1 release.
We keep these. We don't delete. Most of them have been marked as
obsolete or hidden. But we don't delete stuff. You should still find
2.5 documentation out there on plone.org, but it's not as prevalent as
the 3.x docs. This is mainly because we have had a more focused effort
on documenting 3.x than we had for 2.5. Now, we don't actively write
2.5 docs and we haven't for awhile. But the info is still around for
those that need it.

As for resources, well you know the story. The doc team is always
strapped for resources so no, we don't have the capacity to support
multiple versions. It's not something we can even as the team to do
because we just don't have enough regular volunteers that contribute
to writing docs. But we will keep the 2.5 docs we do have. I don't
anticipate us making them hidden anytime soon as so many people still
do use 2.5...we just don't focus on writing anything new for that
version.

J.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Dylan Jay-4 () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Israel Saeta Pérez

On 19/04/2009, at 7:23 PM, Israel Saeta Pérez wrote:

> On Sun, Apr 19, 2009 at 9:43 AM, Raphael Ritz wrote:
>> When it comes to documentation I would not purposefully remove
>> the old stuff per default but simply mark it as such, e.g., like
>> Dylan suggested. I don't see any harm in keeping old documentation
>> around as long as we do it in such a way that people don't get
>> confused.
>
> I definitely agree with keeping documentation for older versions.
>
>> So for me, the question boils down to: how to best avoid potential
>> confusion without simply removing the old stuff?
>
> The "applies to" (archetypes) field of the PHC content-types is
> exactly for that. Some time ago somebody removed the Plone 3.x choices
> for this field and left only Plone 2.5, Plone 3.3. The good part is
> that this frees us from having to bump the "applies to" field of every
> doc that doesn't need changes for the upcoming version, but on the
> other hand it bans us from fine-specifying the version like in the
> docs only valid for 3.3.
>
> I'd prefer to keep it as is now, since the aren't so many changes
> between some version of Plone 3 and the following one, and having to
> "duplicate" all docs when only a paragraph is added to some docs isn't
> very efficient IMO. A more pragmatic approach is specifying that

I'm happy to write the scripts needed that would, before each new  
plone release copy all "official" manuals from the 3.3 folder to a new  
3.4 folder for instance. In addition a "current" folder could alias  
the latest version.

I can see where you are coming from that logically, duplicating  
content seems somehow cludgy but think about it this way.

If there was a need to delete documentation no longer relevant to 3.4  
for instance, you could do that in the 3.4 version without any concern  
for affecting readings using older versions. It will make editing  
easier.

As manuals get larger as the users manual and the theming manual are,  
the "applies to" field becomes meaningless and the documentation is  
going to become confusing to read with "if you're using 3.4 do this...  
if you're using 3.3 do this..."

I personally find it very frustrating to do a search for documentation  
only to find what I'm reading doesn't apply the version I'm using.  A  
version number in the url and browser title and headings is going to  
more quickly spotted than teh "applies to" subheading. Finding your  
version in amounts a long list of numbers is also harder than  
installing Plone 3.4 and seeing 3.4 in the title and knowing you're  
reading the best docs.

Version numbers in the url also mean you will know if the  
documentation applies to your version BEFORE you click on it from  
google or plone search.

If you're worried about diskspace... is that really an issue?

If you're worried about maintaining different versions and doing the  
same edits multiple times... I don't think there is a need to. Once a  
version is old don't update it.

Tell me if I'm being an idiot but I'm failing to see any downside  
other than "it's not how we do it now". Clarity for our readers is  
paramount right?

I also really don't want cause an upset so if you guys don't like idea  
and none of the above convinces you then I'll drop the idea.

Dylan.
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
vedaw () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by JoAnna Springsteen
The goal is to release documentation that is older into the broader
"knowledgebase" space. And Joanna's right, we won't be removing any
documentation, we're just going to flush it out of the core documentation
area.

Since we're moving toward a manual-based system, it makes sense to create
them in a way that we can flag them as being specific to a given major
version of Plone.

Within a given version, we can still indicate where something applies to 3.3
or 3.4 within the 3.x manual, since there will obviously be incremental
change, but I don't think we should have new manuals for minor versions of
Plone, just from the maintenance standpoint.

- Veda


On 4/19/09 7:55 AM, "JoAnna Springsteen" <[hidden email]> wrote:

> When someone creates a doc on plone.org, there is a place to select
> which version of Plone this doc applies to.
> I believe Veda and SteveM have plans of doing a reorganization of how
> information is presented on the Documentation landing page. Because we
> already capture this data, all we have to do is clearly link to it.
>
> As for what we keep...We still have docs that support the 2.1 release.
> We keep these. We don't delete. Most of them have been marked as
> obsolete or hidden. But we don't delete stuff. You should still find
> 2.5 documentation out there on plone.org, but it's not as prevalent as
> the 3.x docs. This is mainly because we have had a more focused effort
> on documenting 3.x than we had for 2.5. Now, we don't actively write
> 2.5 docs and we haven't for awhile. But the info is still around for
> those that need it.
>
> As for resources, well you know the story. The doc team is always
> strapped for resources so no, we don't have the capacity to support
> multiple versions. It's not something we can even as the team to do
> because we just don't have enough regular volunteers that contribute
> to writing docs. But we will keep the 2.5 docs we do have. I don't
> anticipate us making them hidden anytime soon as so many people still
> do use 2.5...we just don't focus on writing anything new for that
> version.
>
> J.
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Plone-docs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-docs


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Raphael Ritz () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
Veda Williams wrote:

> The goal is to release documentation that is older into the broader
> "knowledgebase" space. And Joanna's right, we won't be removing any
> documentation, we're just going to flush it out of the core documentation
> area.
>
> Since we're moving toward a manual-based system, it makes sense to create
> them in a way that we can flag them as being specific to a given major
> version of Plone.
>
> Within a given version, we can still indicate where something applies to 3.3
> or 3.4 within the 3.x manual, since there will obviously be incremental
> change, but I don't think we should have new manuals for minor versions of
> Plone, just from the maintenance standpoint.

Once we have the manual in place - and it looks like we come a long way
already - I'm not sure it would produce much of a maintenance overhead
to even release the manual for minor versions.

Just look at, e.g., http://www.python.org/doc/versions/
Most of the stuff there is identical across versions but as Dylan
points out this is much easier to deal with from a user's point
of view.

Raphael

>
> - Veda
>


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
JoAnna Springsteen () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by vedaw
> Within a given version, we can still indicate where something applies to 3.3
> or 3.4 within the 3.x manual, since there will obviously be incremental
> change, but I don't think we should have new manuals for minor versions of
> Plone, just from the maintenance standpoint.


+1. we're not messing with brand new manuals for every incremental
version. And the way the framework team handles PLIPs these days, we
shouldn't ever have to. The next series of docs will be for the 4.x
versions of Plone.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Darci Hanning () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Raphael Ritz


On Sun, Apr 19, 2009 at 12:52 PM, Raphael Ritz <[hidden email]> wrote:
Veda Williams wrote:
> Within a given version, we can still indicate where something applies to 3.3
> or 3.4 within the 3.x manual, since there will obviously be incremental
> change, but I don't think we should have new manuals for minor versions of
> Plone, just from the maintenance standpoint.

Once we have the manual in place - and it looks like we come a long way
already - I'm not sure it would produce much of a maintenance overhead
to even release the manual for minor versions.

Part of the original reason for this email is that we had a small burp in our process. In Plone 3.3, the way versioning is displayed/implemented is completely different than it is in versions 3.0-3.2. In the process of updating this page in the Plone 3 user's manual, we temporarily lost the page that documented how it worked in the previous versions (it was overwritten).

The warning here is to make sure to do something like this:
[from http://plone.org/documentation/manual/plone-3-user-manual/]

And not to update the current page without retaining the previous information.

Cheers,
Darci


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
JoAnna Springsteen () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
> Part of the original reason for this email is that we had a small burp in
> our process. In Plone 3.3, the way versioning is displayed/implemented is
> completely different than it is in versions 3.0-3.2.

This is the kind of stuff that the framework team shouldn't be doing.
tsk tsk. /me wags finger
But seriously, as we are more involved with documenting PLIPs, we
should catch this kind of thing early and point out the ramifications
of making large changes like this.

> In the process of
> updating this page in the Plone 3 user's manual, we temporarily lost the
> page that documented how it worked in the previous versions (it was
> overwritten).

Would something like working copy support on plone.org help?


> The warning here is to make sure to do something like this:
>
> Versioning (Plone v3.0 - Plone v3.2)
> Versioning (Plone v3.3+)
>
> [from http://plone.org/documentation/manual/plone-3-user-manual/]

Yeah, this is ugly but it works. Better than having an entirely new
manual for 3.3.


> And not to update the current page without retaining the previous
> information.

again, working copy support ? other ideas? Personally we should be
using versioning on our docs anyway. Is this a requirement we've
talked about for the upcoming PHC changes? Maybe we should add this?

J.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Wichert Akkerman () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
Previously JoAnna Springsteen wrote:
> > Part of the original reason for this email is that we had a small burp in
> > our process. In Plone 3.3, the way versioning is displayed/implemented is
> > completely different than it is in versions 3.0-3.2.
>
> This is the kind of stuff that the framework team shouldn't be doing.
> tsk tsk. /me wags finger

Yes and no. I agree this change changes behaviour in a way that people
might not be expecting, which is not desirable in the 3.x series. There
were two good reasons to still make it though: most packages keep the
version numbers in setup.py, version.txt and metadata.xml in sync and
will see no change, and Plone no longer mixes up profile and package
versions which was a bug and was starting to confuse people. The
distinction is important, and I felt that this was warranted to set
things straight.

Wichert.

--
Wichert Akkerman <[hidden email]>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Graham Perrin () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by JoAnna Springsteen
Hanno Schlichting wrote:

> 2.5 is not supported anymore in terms of maintenance updates of
> the codebase (2.5.5 was released in Dec 2007).

OK, thanks :) I see that whilst
<http://plone.org/products/plone/releases/2.5> is unsupported,
<http://plone.org/products/plone/releases/2.5.5> is a supported maintenance release including a fix for a security issue.

(I would expect security fixes for 2.5.x, but I would not want to hear that 2.5.5 is unsupported.)

Apologies for the earlier misunderstanding.

JoAnna Springsteen wrote:

> Would something like working copy support on plone.org help?

+1

Absence of working copy support is one of the reasons that I have been so quiet on the documentation front.
Israel Saeta Pérez () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Wichert Akkerman
On Mon, Apr 20, 2009 at 8:41 AM, Wichert Akkerman <[hidden email]> wrote:

> Previously JoAnna Springsteen wrote:
>> > Part of the original reason for this email is that we had a small burp in
>> > our process. In Plone 3.3, the way versioning is displayed/implemented is
>> > completely different than it is in versions 3.0-3.2.
>>
>> This is the kind of stuff that the framework team shouldn't be doing.
>> tsk tsk. /me wags finger
>
> Yes and no. I agree this change changes behaviour in a way that people
> might not be expecting, which is not desirable in the 3.x series. There
> were two good reasons to still make it though: most packages keep the
> version numbers in setup.py, version.txt and metadata.xml in sync and
> will see no change, and Plone no longer mixes up profile and package
> versions which was a bug and was starting to confuse people. The
> distinction is important, and I felt that this was warranted to set
> things straight.

As far as I've understood, Darci was talking about:

    * Versioning (Plone v3.0 - Plone v3.2):
http://plone.org/documentation/manual/plone-3-user-manual/managing-content/versioning-plone-v3.0-plone-v3.2
    * Versioning (Plone v3.3+) :
http://plone.org/documentation/manual/plone-3-user-manual/managing-content/versioning-plone-v3.3

not about the changes in the QuickInstaller.

-- israel

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
Israel Saeta Pérez
Hanno Schlichting-3 () Re: Keep documentation for previous versions when updating it to reflect new behaviour and features
Reply Threaded More More options
Print post
Permalink
In reply to this post by Graham Perrin
Graham Perrin wrote:
> Hanno Schlichting wrote:
>
>> 2.5 is not supported anymore in terms of maintenance updates of
>> the codebase (2.5.5 was released in Dec 2007).
>
> OK, thanks :) I see that whilst
> <http://plone.org/products/plone/releases/2.5> is unsupported,
> <http://plone.org/products/plone/releases/2.5.5> is a supported maintenance release including a fix for a security issue.

I clarified the "supported" status on the release pages. 2.5.5 is now
marked as unsupported, as that is our policy for many months now. The
2.5 series doesn't get security updates anymore. See
http://plone.org/products/plone/security/advisories/cve-2008-0164 for
the first CVE that didn't see a hotfix for Plone 2.5 anymore.

Hanno


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
1 2