Proposal: rename `.tito/tito.props` to `.tito/props.ini`

[Malix-Labs]

Subject

.tito/tito.props

Problem

1. File Extension : It seems to have an ini file format but has a .props file extension (doesn't get highlighted nor linted properly)
2. Redundancy : duplicated "tito"

Solution

Rename it to .tito/props.ini

Workaround

Point 1 only

VSCode

Append these lines to your settings.json :

"files.associations": {
    "tito.props": "ini"
}

[FrostyX]

Hello @Malix-Labs, thank you for the RFE.

I completely agree with your reasoning and that the .tito/props.ini would be better. We also have .tito/releasers.conf so .tito/props.conf would be more consistent even though it sounds ridiculous. Personally, I would land at .tito/tito.conf even if there is the mentioned redundancy.

But I am not sure whether it is something worth breaking the backward compatibility for. IMHO it isn't. There are blog posts about Tito that would get outdated, upstream repos would have to migrate to the new config name, etc.

The manual page man tito.props says

Project settings can be stored in files:
GITROOT/.tito/tito.props
GITROOT/SOME/PACKAGE/tito.props

so maybe it will be possible to add a third file to this and let tito init create a symlink from tito.props to the new file to preserve backward compatibility and slowly deprecate the old one. But that again sounds like too much hassle for too little benefit.

What are your thoughts?

[Malix-Labs]

Hello @FrostyX, thanks for your time reading and replying to my issue !

But I am not sure whether it is something worth breaking the backward compatibility for. IMHO it isn't. There are blog posts about Tito that would get outdated, upstream repos would have to migrate to the new config name, etc.

Wouldn't it be possible to make both file work (with a priority order ofc), and to make tito init create the new file names instead?

I think this is the best of both world, and what has worked for most of the project I contribute too, such as VSCode and Vite

so maybe it will be possible to add a third file to this and let tito init create a symlink from tito.props to the new file to preserve backward compatibility and slowly deprecate the old one. But that again sounds like too much hassle for too little benefit.

This is also possible indeed but would perhaps be more work ? Technically, it might be better indeed