On 12-06-19 11:07 AM, Mck wrote:
On Tue, 2012-06-19 at 09:23 -0400, Nicolas LE BAS wrote:
We like to upgrade MustacheRenderer to use the latest version of the
mustache java libraries. It was 0.6 and is now at 0.8.
This code looks to be largely rewritten between these versions.
What's shall be tiles' ways of handling support for different upstream
versions?
I'm not sure we want to support different upstream versions.
Maybe not actively no.
It may be fine to just release minor.minor versions, eg
tiles-request-mustache-1.0.1.
But we should state clearly which version supports which upstream
version. I don't think it's our place to be dictating the upstream
version the client must be using. Clients may well be stuck on a
previous version and not able to upgrade without some effort... In this
case clients will also be stuck using a previous tiles-request-mustache
version. It's not such a problem now but it kinda unfortunately ties the
whole tiles-request-* stack together... Is this "simple" way to go ok
for now? (It is for me but it's nice to have it cleared).
I don't see it as "dictating the upstream version to clients". And it's
not our place to dictate maintenance policy to upstream either. Let's
assume upstream made their decision for a good reason.
I agree about being clear, and the "simple" way to go is ok with me:
- proceed with the upgrade as with any new feature
- document it in a JIRA issue in order to include it in the release notes
Now if we should encounter a real (i.e. end-user level) incompatibility,
then we'll have to consider forking the mustache implementation. Also
note that as long as we do not change the few key classes in
tiles-request-api, we should be able to use an older version of
tiles-request-mustache with any version of tiles-request.
Nick
PS: That's a good point you raise, and actually that's a problem we
encounter with spring integration. Spring doesn't provide a stable SPI
for view technology providers (ViewResolver is an API, not an SPI), and
that's why the tiles-request/spring integration would be better
maintained at spring. We can't release a version of tiles for every
version of spring.
