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.
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.
>
>