Yeah, introducing a new more focused prefix constant just for properties
would be better.
Sounds like consensus so far though is to just hold off for a fix that
refactors DistributionConfigImpl enough to make a good clean change to look
for both properties files.
-Kirk
On Thu, Oct 13, 2016 at 4
PROPERTY_FILE_PREFIX ?
On Thu, Oct 13, 2016 at 3:05 PM, John Blum wrote:
> -1 for introducing this change as well.
>
> Also -1 for introducing any additional constants/workarounds. Either fix
> it the way it should be fixed or do nothing at all.
>
> On Thu, Oct 13, 2016 at 2:45 PM, Kirk Lund w
-1 for introducing this change as well.
Also -1 for introducing any additional constants/workarounds. Either fix
it the way it should be fixed or do nothing at all.
On Thu, Oct 13, 2016 at 2:45 PM, Kirk Lund wrote:
> -1 at this point I'm against making this change for 1.0.0
>
> I'll still work
-1 at this point I'm against making this change for 1.0.0
I'll still work towards fixing GEODE-1466 properly but it'll be fixed on
develop within the next week or so.
-Kirk
On Thu, Oct 13, 2016 at 2:26 PM, Udo Kohlmeyer
wrote:
> If such a change is to be introduced.. maybe we call it `SYSTEM_
-1 for including any of this in the 1.0 release. Let's get that release out
the door!
-Dan
On Thu, Oct 13, 2016 at 2:26 PM, Udo Kohlmeyer
wrote:
> If such a change is to be introduced.. maybe we call it `SYSTEM_PREFIX` or
> something more generic that we could use within the Geode.
>
> Then we
If such a change is to be introduced.. maybe we call it `SYSTEM_PREFIX`
or something more generic that we could use within the Geode.
Then we could hopefully cover many to most `gemfire` vs `geode` renaming.
But I agree with @Anthony, if we aren't 100% certain about a change then
we should hol
How about introducing a new GEMFIRE_FILE_PREFIX attribute that will default
to "geode" while leaving GEMFIRE_PREFIX default to "gemfire"? Is this
something that will work?
On Thu, Oct 13, 2016 at 1:48 PM, Anthony Baker wrote:
> Hmmm, you would think it would be easier to change a file name :-)
>
Hmmm, you would think it would be easier to change a file name :-)
I don’t think we should be pushing destabilizing changes into a release branch.
If the changes aren’t ready now we always pick them up for the next release.
Anthony
> On Oct 13, 2016, at 1:13 PM, Kirk Lund wrote:
>
> I'm curr
