On 07/03/2017 06:53 AM, Brian Exelbierd wrote:
On Thu, Jun 29, 2017, at 10:34 PM, Matthew Miller wrote:
On Thu, Jun 29, 2017 at 10:29:29PM +0200, Brian Exelbierd wrote:
However, considering this from a different angle, a LAMP stack module,
for example, might just need to make a certain API/ABI promise and then
it could roll for quite a while. This would be without regard to the
changes in the underlying software versions, as long as what was
promised on the wrapper was still met. If this is the case then
"collections" are no different from "single applications."
In terms of EOL, right. But collections have no obvious intrinsic
version number to use as the major stream identifier, whereas
applications (and environments and stacks) do.
I think we should allow for an arbitrary version number when the
collection is not obviously tied to a specific release/user space.
However, I think that should strongly be discouraged and if at all
possible the motivating software in the collection's version number
should be used. This is not something that should ever require heavy
debate, imho. I trust packagers to make the right decision.
regards,
bex
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
one quick point, even in the case of "single applications" what is
included may not be obvious. For example, does this mariadb module
include the client? how about python bindings? For what versions of
python? You quickly run in to problems when trying to fit information in
to the name that isn't the name of the thing. Major +1 to the points
about NOT encoding information in to the "wrong" metadata element.
Again, struggling with how do we capture all this? I believe it should
be in the module guidelines, however, it would be useful to capture
these discussions so that when we (I, for sure :) ) forget, we can see
the "threads". Should we shift this kind of discussion to the "wiki
discussion" page? Should we move the guidelines to a pagure repo and do
it with PRs, issues, etc?
Langdon
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
