Re: FOP Release Automation

[Pascal Sancho <ps...@gmail.com>]

Hi,

If we go to an svn:externals set in CMS repo, pointing to FOP trunk
doc, and 2 last FOP tagged doc, we should take care about having no
change in TAGs. Perhaps a pre-commit hook can do the job here, warning
the committer, or forbidding the commit propagation.

2014-05-30 23:34 GMT+02:00 Robert Meyer <rm...@hotmail.co.uk>:
> I'll definitely look into those. I'm going to be away on holiday now for a
> week or so but will continue once I get back.
>
> Many thanks!
>
> Robert
> ________________________________
> From: Clay Leeds
> Sent: ‎5/‎30/‎2014 17:24
> To: Apache FOP
>
> Subject: Re: FOP Release Automation
>
> Agreed, ‘some’ people wouldn’t be happy with that. ;-)
>
> I wonder if the CMS Web interface could be extended to allow for a few
> keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc.
>
> The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown
> Editor, which is extensible:
>
> https://web.archive.org/web/20110121060932/http://wmd-editor.com/
>
> (site’s down & hasn’t been updated since 2011)...
>
> or
>
> https://code.google.com/p/wmd/
>
> We might still need to do some ANT hanky panky, but at least if we could
> leverage WMD’s extensibility it would help us get where we’re trying to go?
>
> Clay
>
> On May 30, 2014, at 7:19 AM, Robert Meyer <rm...@hotmail.co.uk> wrote:
>
> Hi,
>
> I like the simplicity of your idea, but the web interface is not so easy to
> dismiss unfortunately.
>
> If you do have a copy with those tags in, if any changes are made on the web
> interface then that copy would become out of date.
>
> We could always shutdown the web interface, but I don't think too many
> people would be happy with that ;-)
>
> Regards,
>
> Robert
>
> ________________________________
> From: simonsteiner1984@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
> Date: Fri, 30 May 2014 14:48:15 +0100
>
> Hi,
>
>
>
> Simple way is to store docs inside fop repo:
>
>
>
> Fop/docs/index.markdown
>
>
>
> Inside markdown file you reference ant properties eg:
> ${version}
>
>
>
> Then you call which does ant expandproperties and calls markdown to html
> tool:
> ant docs
>
>
>
> Then you call which does a zip, scp and unzip of html files to web server:
> ant upload-docs
>
>
>
> This method doesn’t support web interface of editing files but I don’t see
> how this is really needed.
> If I submit a patch to fop it should also contain doc changes rather than
> having separate repo and patch for that.
>
>
>
> Thanks
>
>
>
> From: Robert Meyer [mailto:rmeyer@hotmail.co.uk]
> Sent: 30 May 2014 14:05
> To: fop-dev@xmlgraphics.apache.org
> Subject: RE: FOP Release Automation
>
>
>
> Hi,
>
> After investigating your suggestions Clay I have found that svn-hooks can't
> be used for the purpose we require unfortunately as it may lead to problems
> with how SVN operates and also may have some unexpected results with files
> being committed. This is stated in the documentation under "Creating
> Repository Hooks" highlighted in the warning red box further down:
>
> http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html
>
> Pascal, I agree that the process is fairly straightforward, but I have been
> asked to automate this further so am just looking into ideas presently.
>
> I think a possible way forward then would be to use your suggestion Pascal
> of placing the versioned docs for the site inside the FOP repository for
> their associated version. These can then be referenced using the
> svn-externals from the main site repository.
>
> In addition to this, the main site files (which would need to be updated)
> could contain tags for the last three versions which would be replaced using
> Clay's markdown pre-processor suggestion. The pre-processor would replace
> the tags with values stored in a properties file in the main site
> repository.
>
> To create a release, the user would need to update the svn-external
> references to account for the new version and update the properties file for
> tag replacement. When the properties file is pushed it will be read by the
> custom markdown pre-processor and display the new version when rendered.
>
> Those two stages could be done using a single script to simplify things
> further, but the main complication is getting the markdown pre-processor
> working. From looking at this page:
>
> http://www.apache.org/dev/cmsref.html#markdown
>
> I am guessing we use PyPy (Python Markdown) which supports extensions, so I
> will look at this shortly to try out a small example and investigate the
> feasibility of doing this. There is also the matter of updating the
> versioned documents for each FOP when a new version is released, but maybe
> this could be done with the pre-processor as well.
>
> Anyway, let me know what you think.
>
> Regards,
>
> Robert
>
>



-- 
pascal