On Wed, Jun 20, 2018 at 1:52 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > On Tue, Jun 19, 2018 at 04:21:25PM -0500, Eric Sandeen wrote: >> On 6/19/18 3:57 PM, Luis R. Rodriguez wrote: >> > But from a generic file format point of view, a version typically does >> > make sense for a slew of reasons, but it is typically the not known, the >> > unexpected, for which it can be a life saver. >> > >> > Things that I can mention other than what you mentioned (whether or not >> > they are good, this is just a list of crazy things): >> > >> > 1) We move from using our own parser to e2fsprogs profile parser (recall >> > that my studies revealed it was the smallest) or lib_iniconfig (more >> > robust, and widely used, however a kitchen sink compared to e2fsprogs >> > profile parser) >> > >> > Both however support the INI format we are using. >> > >> > The version however may help to make the old parser not barf if >> > say we added some magic in the future which would make the old >> > parser barf. >> >> ... if the file format does not change, a parser change doesn't matter, and >> a version change would be pointless. > > It can. Consider support for different comment styles. IMO comments are part of the format and if they change, then the format itself was changed too. So I find it difficult to see any practical use for a config version, but all arguments about it were already said. Still, if we end up with something like this, let's make the section to be optional. If we ever happen to find ourselves in such situation and we need the version check as an emergency brake, then we can specify that the v2 format has to begin with version=2. The old parser will understand it and abort, but if it is not present, it is equal to version=1 and we will not pollute the configs in the meantime. Cheers, Jan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
