Manage kettle version specific changes

[GoogleCodeExporter]

So far I haven't bothered managing changes on a per kettle version basis. There 
was always a kind of unspoken ideal to make cookbook work regardless of the 
kettle version. 

However, there have been a few changes that don't add functionality and only 
make cookbook work with a newer kettle version. Some of these might be 
backwards compatible, some might not. I don't really know at this point.

This has to change. There are alternative directions:
1) cookbook gets tied to the kettle version and users have to make sure they 
match the correct cookbook version with the kettle version they're running.
2) coobook comes with some logic that detects the current kettle version and 
somehow applies that at runtime.

Obviously option 1 is easiest from a development perspective, option 2 is 
easier for the user. I prefer to go with 2 unless that proves to be very 
difficult.

A simple way to implement 2) would be to have one master job that is made to 
work on any kettle version, which references sub jobs and transformations 
dynamically. We can then create sub jobs and transformations prefixed by a 
kettle version number and select those at runtime. 

This could either be very simple - say one set of jobs and transformations per 
kettle major version - or very complex - say a discovery process that finds the 
closest matching jobs and transformations based on the full version number.

I would very much like feedback on this idea. It would also be helpful to know 
which versions of kettle are currently being used by the community, and if 
possible which revision of cookbook people are using since I frankly have no 
idea which cookbook revision works with which kettle version.

Original issue reported on code.google.com by roland.bouman on 8 Sep 2014 at 11:59

[GoogleCodeExporter]

ah, suspect some of those changes are my recent ones.  It's annoying because 
even when you use PDI4 features but save the transformation in PDI5 the XML is 
changed quite a bit - and worse if you're using an EE client.

However, I for one would be more than happy to dump support for PDI4.  Worst 
case scenario if someone is really tied to PDI4 in prod, they can still use 
PDI5 to generate the doco.

I am always a big proponent for upgrading and tracking the latest version 
though, i know others are a lot more conservative than me. (why!!)  So make of 
my comments what you will!

Original comment by d.e.kee...@gmail.com on 8 Sep 2014 at 12:11

[GoogleCodeExporter]

Making cookbook kettle-version proof can be very cute, but I don't think it's 
worth it.

In my scenario most of the jobs in production are made with PDI4 and so 
documentation, but I make new work in PDI5, therefore the needed cookbook 
adjustment.
No new work is planned with PDI4, so no need for cookbook to guess the version 
;) 

I think we can go ahead with PDI5 in trunk, eventually making a PDI4 branch. Or 
zip-freeze a kettle4 version.

Note that I kept the patch minimal and clean (but working). Saving ktr with 
kettle 5 can change it much more.

Original comment by enricomariam42 on 8 Sep 2014 at 2:22

[GoogleCodeExporter]

I held off on some patches purely because of the complexity of keeping it 
minimal as above.  If that went away i could commit a few more bits and pieces.

Original comment by d.e.kee...@gmail.com on 8 Sep 2014 at 2:25