On 07/03/2012 08:20 AM, Pete Muir wrote:
On 3 Jul 2012, at 16:14, James Perkins wrote:
> The main idea behind the supportVersions (probably a bad name) was something like:
> availableVersions: 7.0.0.Final, 7.0.1.Final, 7.0.2.Final,
7.1.0.Final, 7.1.1.Final
> supportedVersions: 7.1.0.Final, 7.1.1.Final
> Just meaning all available version should work, but
everything is only guaranteed to work with the supportedVersions. Maybe a Beta or CR could
be in available, but not fully supported as well. Just a thought that really isn't a
big deal.
Yeah, I guess what I'm not getting, is *what* is supported in that version, as that
will change over time. That's why I was proposing a "labels" system, so you
can tag a version as having a capability (like cli or logmodule-needed or whatever). This
way we keep the info (I think) you want, but make it expandable.
I see now. The more
I think about it, the more I agree. it's probably a
bad idea. Using a properties based approach you describe below would
work for this.
> What I think would be ideal if it's possible would be to have a properties
section with name value pairs. Then things like the -logmodule or -someOtherArgument could
be used for anything.
We could do that as well.
7.0.1.Final:
properties:
arguments: -logmodule
cli: not-available
I like this approach.
> I would think the AS downloads would always be a zip as well. If other consumers have
no use for a packaging type it can be left off. Really if we can have a properties section
it could be used in there if needed.
Let's leave it out for now, and Max can comment when he is back.
Works for me.
I have no real need for it. Just thought if it was useful
for others, I would use it too.
--
James R. Perkins
JBoss by Red Hat