On 06/29/2017 11:27 AM, Josh Boyer wrote:
On Thu, Jun 29, 2017 at 11:19 AM, Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx> wrote:
On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:
I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.
I like simple integer approach and it feels natural from an
engineer's point of view. I think. I can also imagine using
years or years.months, depending on how often the module
maintainer decides to release a new... thing.
Like "tools 2017", "tools 2017.6". *shrugs*
But I don't really have a preference.
I wouldn't include EOL directly in the stream (i.e. branch)
name but I totally agree it needs to be prominently displayed
in any user interface that deals with modules. No matter where
the tools get it from.
I really, really don't want anyone creating new modules without
considering lifecycle. Forcing it into the stream name is:
I agree with lifecycle being required. I disagree completely with it
being in the stream name. It doesn't make sense at all for a large
variety of reasons. It's a cheap hack to get what you really want,
and I think it's just going to incur technical debt we should avoid in
the first place.
Modularity is new. It's different. It will be hard at first. Let's
not hamstring ourselves from the start.
josh
_______________________________________________
devel mailing list --devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email todevel-leave@xxxxxxxxxxxxxxxxxxxxxxx
As I said to Matt on IRC, I agree with the point that metadata should
*not* be encoded in "yet another string" like "name" has been used for a
long time. We need to be very careful of this problem as it is
*incredibly* tempting to use our years of experience with doing this to
basically introduce the problem again. We need to add metadata labels
for new metadata when we need it. We need to try VERY hard not to use
any string to hold more than one piece of metadata. TBH, I fell in to
that trap myself when first talking about it to Matt.
I also am not the biggest fan of the "stream" being a user-defined
thing, rather, I wish it could be something that is more like a computed
amalgamation of the other metadata (this is kinda what Nix does).
However, I am still on the fence on this. Stream != name.. and name is
where "lamp with httpd" kinda belongs.
As I said in another part of the thread (/me hates thread splitting), we
fully expect to have guideline enforcement gating release of modules. We
can very easily require that EOL be provided (whether it be modulemd,
pdc, or something else) as part of that test. In fact, we have planned
for it to be there all along and prominently displayed in UX tools (one
of the very early dev topics). However, the problem of "how to store it"
has come up multiple times because it is HARD. I am also not sure EOL is
something we can just plop in somewhere and then fix it later. So, your
concerns are very valid and well understood, we just haven't figured out
exactly how to solve it. Current plan is PDC along with SLA but I would
need to follow up with Ralph, et al to know if that part got implemented
yet.
Langdon
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
