Closed nealmcb closed 8 years ago
Individual apps generally follow semantic versioning and often have an upgrade path.
But combinations of apps, and starter projects are a little harder to version and upgrade which is why we proposed and are aiming towards something like https://github.com/pinax/pinax/issues/84.
An upgrade path from 3+ year old code is probably not realistic given how much Pinax has changed although some individual apps might be upgradable.
But, in short: apps should be upgradable but something like https://github.com/pinax/pinax/issues/84 is needed for coordinated releases of dependent apps.
@nealmcb Does the answer above answer your question, meaning can I close this issue? 😊
That is a very helpful response - thanks! I'd suggest that it be incorporated into the documentation.
@nealmcb Great suggestion! Would you mind sending a PR for this? It would be awesome and much appreciated :)
I'd be happy to. But I'm having trouble finding which repo has the source of the documentation for http://pinaxproject.com/pinax/faq/ So many repos!
Thanks. See https://github.com/pinax/pinax/pull/104 Since that is in a different repo, I'm guessing that the issue here won't be linked, or at least I don't know how to cleanly link them.
[Well, I stand corrected - thanks github!]
@nealmcb yeah, github does a good job with that
Thank you @nealmcb and @jtauber!
Does Pinax have an easy way to upgrade a site which was based on a previous version? Or are there plans to support something like that?
I.e. is Pinax careful to maintain backwards-compatibility, or document an upgrade path when compatibility breaks, so it can be versioned and managed like a code library?
Or is it just intended to be a template that we fork from, in which we forever own maintenance, fixing security issues, etc?
I don't see responses to the questions about this on the mailing list. E.g.:
I guess this is related to https://github.com/pinax/pinax/issues/84 but it's hard to even find the right issues thread to ask this question on.