trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunnar Tapper <tapper.gun...@gmail.com>
Subject Re: [DISCUSS] Documentation Versioning
Date Thu, 07 Jul 2016 06:16:47 GMT
Hi Steve,

>From what I see, these variables are defined in core/sqf/sqenvcom.sh.
However, TRAFODION_VER_MINOR is set to 1 in the main branch already. That
works once the documentation updates are done as part of the release rather
than post release as today.

For now, what can be done to override these variables for the documentation
part of the build?

Gunnar

On Wed, Jul 6, 2016 at 4:29 PM, Steve Varnau <steve.varnau@esgyn.com> wrote:

> Gunnar,
>
> Yes, that makes sense to me.
>
> Either that, or the docs could use only the major/minor numbers of the
> release -- at least for the directory path where to generate the docs.  We
> probably want the update number in the docs, but only want one version per
> minor release.
>
> docs/${TRAFODION_VER_MAJOR}.${TRAFODION_VER_MINOR}
>
> --Steve
>
>
> > -----Original Message-----
> > From: Gunnar Tapper [mailto:tapper.gunnar@gmail.com]
> > Sent: Wednesday, July 6, 2016 3:09 PM
> > To: dev@trafodion.incubator.apache.org
> > Subject: [DISCUSS] Documentation Versioning
> >
> > Hi,
> >
> > I noticed that Steve 2.0.x header for the documentation. I think this is
> > preferable.
> >
> > However, I know that we want to move to a model where the documentation
> > update is part of the release rather than done against the master post
> > release.
> >
> > The current scheme is that we place documentation in a latest directory
> as
> > well as a versioned directory. This means that you have to; for example,
> > build 2.0.x documents setting $TRAFODION_VER to "2.0.0" to ensure that
> the
> > documents are placed on the correct versioned directory. The result will
> > be
> > that the version-dependent documents are placed in
> > http://trafodion.apache.org/docs/2.0.0/*.
> >
> > Moving forward, I think it'd be better if we create a $DOCS_VER or
> > something like that to allow for dot releases without having to create
> dot
> > releases of the documentation.
> >
> > Thoughts?
> >
> > --
> > Thanks,
> >
> > Gunnar
> > *If you think you can you can, if you think you can't you're right.*
>



-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message