On 22.02.2012 14:48, Josef Reidinger wrote:
from my experience with yast modules, there is quite
strange part which
contain various backward compatible stuff for old autoyast profiles. It
is that really the case?
In the core for example, I have some compatibility code but not really
much. I don't know how it is for other modules but until now I did not
really see that as a problem.
Another point is that I think the XML should not change too much at all.
I don't like the idea that the customer can use all kind of different
XML syntax for one module that are valid for one or another distribution.
makes perfect sense to have backward compatibility in
this area and I
am sure that customer likes it.
it's essential. Without that autoyast would be unusable :)
What can be improved is way how we do it. Now it is
mixed into every
module and it is not much tested, so sometime we get strange bug
report, that something stop working.
I did not see so many bugreports triggered by incompatibility but maybe
I'm wrong with that and we really have a problem here.
I see quite nice way how to solve it in kiwi, so maybe
we can inspire:
1) code always support only the latest schema, no backward compatibility
2) old xml files is before usage transformed via XSLT, so backward
compatibility is preserved and separated
I know the kiwi approach too but I'm not sure if we can/should go that
way with autoyast.
It would require a version number for each section in the XML and even
worse, the customer needs to know what version number he needs to put
into the XML section - often he will leave out the version number
It would require each yast maintainer to learn xslt and to maintain the
xslt file. To be honest, that does not even work for the RNC files and
those are a lot less complex compared to XSLT.
This way we have separate layer for backward
compatibility. We can also
provide easy tool for customers how to update to the latest schema. We
can also more easily test it. It is located in one place.
why is it located in one place then? Every yast module maintainer has to
maintain the XSLT file by himself. It's not so different from now,
except that you don't fix compatibility in Import()/Export() but in XSLT
What do you think about such solution?
I'm open minded for that approach and I'll think about it but for the
moment I'm not convinced it's the best way to go + I'm not sure if we
have the problem we want to fix here.
I'd say your yast module should have a valid and expected XML snippet of
your module in the code, as a comment, above the Import() and Export()
Then you'll always know what to expect on import and what you need to
export when you look at the code.
ciao, Uwe Gansert
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
- Blog: http://suse.gansert.net
listening to: "Ain't It Mad Yet (b mix)" by :Wumpscut:
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org