Is this something worth conducting an informal vote on, to see where the
community sits? Both sides (including/not including these changes) seem
to make a lot of sense. I'd be interested in hearing from a few uPortal
institutions which they'd prefer, in order to help make the final
decision. Those places might not follow uportal-dev.
---- Cris J H
On 12/10/2010 10:49 AM, Eric Dalquist wrote:
For someone that has customized their 3.2 pom locally merging a 3.2.5
release without the filtering changes should be nearly painless. The
only changes we make between patch releases might be the parent pom
reference and some properties for dependency versions so there won't be
many conflicts. Where as if we apply the filtering changes anyone that
has similar changes or other modifications to the same files now has to
deal with merging conflicts. That is the concern and the issue we really
try to only have happen for minor or major releases, not patch releases.
-Eric
On 12/09/2010 10:18 PM, Drew Wills wrote:
On 12/9/2010 7:26 PM, Eric Dalquist wrote:
Adding a new feature that causes pain during a merge is more
questionable since we don't need to do that to fix some other issue.
Agreed 100%. My point here is that (1) you only get this pain if
you've customized the pom (if you haven't there's no merging) and (2)
if you *have* customized the pom, you'll feel this pain, and to the
same degree, whether we include this enhancement or not.
drew
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
