On 5/29/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:

I was thinking copying the pages in Confluence itself (so the Confluence
markup, not the HTML).

If that's not easily possible, then I think we should migrate the
documentation outside of Confluence to a system that scales better, both
in
terms of versioning and editing/aggregation.   I'm thinking something like
Textile/Markdown wrapped with Haml+Sass and everything sitting in a
separate
section of our SVN.


Markdown is slightly easier for authoring, it reads more like text you'd
want to read (when not formatted as HTML), but you sometimes bump into
can't-quite-do cases. Textile deals with those better, at the expense of
something that looks a little more like a markup language.

I personally prefer Textile if the expected output is HTML.

Of course, the state of the art is editing either one using a text editor,
and SVN managing the versioning yourself.

Assaf

And we need to start exporting the Confluence site as backup!

alex



On 5/29/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
>
> Are you suggesting saving the HTML files or the Confluence markup? All
> those pages include a lot of other smaller pages, backing them up could
take
> a little while. I guess we could come up with some little smart spider
> script for Confluence though.
>
> Matthieu
>
> On 5/29/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:
> >
> > How about versioning only the documentation (user guide, programmer's
> > guide, BPEL compliance, javadoc) instead of the whole site?   That
way, we
> > could have a documentation index that would include all versions of
the
> > documentation.   We could do this by copying only the relevant
documentation
> > pages in the same space.  The other pages are 'live' documents and I
would
> > rather have people always access the latest version from the website (
> > e.g. homepage, roadmap, ...).
> >
> > This option, like option 2 below, offers the advantage that we can go
> > and patch/augment the documentation for past versions if need
be.  This is
> > useful to document known bugs, limitations, etc.
> >
> > alex
> >
> >
> > On 5/29/07, Matthieu Riou < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi guys,
> > >
> > > It's a good idea to check our full website for 1.0 in, so it can be
> > > retrieved in case of needs and also published at some different
> > > location
> > > later on when we'll be updating everything for the next release. So
we
> > > can
> > > either:
> > >
> > > 1. Check it in the release branches -> looong checkout
> > > 2. Create a new site directory beside trunk, tags and branches to
hold
> > > the
> > > different site versions (like site/1.0).
> > >
> > > I'd personally go for #2, any strong opposing opinion? Bike shed
bait.
> > >
> > >
> > > Matthieu
> > >
> >
> >
>

Reply via email to