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 completely. 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 files.

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() function. 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 Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: "Ain't It Mad Yet (b mix)" by :Wumpscut: -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org