On 2/8/11 8:16 AM, Justin Lee wrote:
> I'd rather move it than put it on it's own release cycle. We did that
> early on and it just made for awkward release numbering wrt the rest
> of grizzly. If we wanted that route, we could just create a new
> source repo under the grizzly project and move it there. In essence,
> make it a subproject.
Understood. Was just throwing another alternative out there.
>
> On 2/8/11 11:07 AM, Ryan Lubke wrote:
>> On 2/8/11 7:56 AM, Justin Lee wrote:
>>> It's come up a few times over the last year or so I thought i'd make
>>> a formal discussion out of it. It's been suggested that since,
>>> especially right around glassfish release time, we churn through a
>>> lot of releases for tweaks to how grizzly-config works that perhaps
>>> it better belongs in the glassfish tree. It would solve some of
>>> that churn to be sure. I'm not sure how if feel about it. It's
>>> less obvious that it can be used without glassfish in the grizzly
>>> tree. But then, on the other hand, I'm not sure it has much
>>> traction outside of glassfish anyway. Keeping it in grizzly is a
>>> great barrier against encroaching glassfish dependencies for those
>>> standalone users.
>>>
>>> Anyway, what does everyone think about that one?
>>
>> +1 to either move it, or start having it on a release cycle
>> independent of grizzly. Like you've stated, we've had quite a few
>> releases that contain only grizzly-config changes. Ultimately, if
>> it's only GF that's using grizzly-config, I'd like to avoid a full
>> grizzly release that contains fixes for something other developers
>> never use.
>>
>>