We could spin plugins off into their own project, with their own release
cycle, but I'm afraid we don't have the development support to maintain
and release all those plugins. By keeping them in the Struts 2 release
cycle, we ensure they are maintained and supported. Ideally, yes, they
would have their own release cycle, but I don't want to make the same
mistake we did when we split up Struts 1 by creating subprojects for
which there was no developer support.
Don
Ted Husted wrote:
> Would a plugin even need to be part of the core or extra JAR?
>
> Other products based on plugins tend to distribute each plugin
> separately.
>
> Sometimes plugins come bundled with a greater release, but, in most
> cases, I believe any of the bundled plugins could be released
> separately if a fix were needed.
>
> -T.
>
> On 10/6/06, Don Brown <[EMAIL PROTECTED]> wrote:
>> I absolutely agree! That is one of the advantages of the plugin
>> system. What would be the best way to inform users of the
>> "experimental" quality of a plugin? The Linux kernel uses the
>> "experimental" label to inform the user that a particular module
isn't
>> deemed "production quality". Can we do something similar somewhere?
>> Perhaps the table that lists the plugins has an extra column for the
>> quality?
>>
>> Don
>>
>> Wendy Smoak wrote:
>> > On 10/6/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>> >
>> >> The reason I ask is that our 2.0.1 release will be tied to
whatever
>> >> version moniker that XWork uses. If tomorrow's XWork release is
>> tagged
>> >> as "beta", and that cannot change for that set of bits, then the
>> 2.0.1
>> >> release will also be forever beta.
>> >
>> > Struts 2 also has a dependency on a snapshot of Tiles 2, so by that
>> > logic you're stuck at Alpha for Struts 2.0.1.
>> >
>> > This policy of grading a release at the lowest common denominator
>> > doesn't seem to be working out all that well. Different parts
of the
>> > distribution have different levels of 'quality' so to speak. If
you
>> > have an experimental plugin, that's no reason to downgrade the
core.
>> >
>> > Speaking of that Tiles 2 dependency, we need to deploy a
snapshot with
>> > a fixed version number (such as 20061006-SNAPSHOT) so that future
>> > snapshots of Tiles 2 don't break Struts 2.0.1 for Maven users.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
