There has been a little issue with Ubuntu versions.
Kicad v6.0 can’t open the last v5.99 eeschema files because of something related with the date. The message says the file was made with a more recent version than v6.0. So I will wait for a newer v6 version in order to open those files. Fortuntely I have not installed v6.0 in one computer.
That said, so far Kicad has 2 versions: stable and nightly. Now stable is v6.0 and nightly v6.99 the future v7.
What happens with the development branch of 6.0 to become 6.0.0 or 6.1? No idea.
In Ubuntu versions there is only one stable version. So v6.0 overwrites 5.1.12. It seems a little risky. I must admit it is not risky after all. The v5.1.12 projects are automatically migrated to v6.0 when opened with the new version. There is no chance to go back to v5.1.12, but there is no need too. Maybe some extra work has to be made with the libraries but no information is lost.
which gives the base URL and other properties to narrow it down to certain directories.
Other Linux distros have similar definitions for their repos. Ubuntu PPAs (Personal Package Archive) are a kind of repo, that is unofficial and not signed by Ubuntu. Anyone can start a PPA, but users have to trust the publisher.
Repos can encompass a major portion of a Linux distro, or a cluster related packages, or just a couple of packages that the publisher wanted to disseminate.
When considering updates, the highest version of a package of a given name from all active repos wins.
I am in the middle of an important project that will last months more. It contains numerous custom footprints. I am comfortable with 5.1. I have no intention of moving to 6 until I’m not working on something important.
On every system I know about, the kicad-nightly (or equivalent) package reflects the latest development nightly at all times, meaning that it becomes 6.99 immediately when 6.0 is released. These packages/repos do not discontinue at every stable release. Testing builds of the 6.0 branch would be new/different packages (but as far as I know, no Linux distros have packaged these before). So, I think you have different expectations of the package than the packagers do.
So create a repo called 6.99 nightly so that people who volunteer to test the upcoming 7.0 don’t get caught out when it turns into 7.99 without them having done anything. Depending on how the build system is set up, it may only be a matter of creating links or destination directories after a build is done with some scripting and not require separate builds.
I understand how it would be solved if we wanted to do that, just wanted to clarify that this is not how we currently treat the nightly repos on any platform. Users who use nightlies have the burden of keeping track of the release schedule and deciding when they want to switch back and forth between a nightly and stable release based on their risk tolerance.
Any way to produce and put out some sort of vote-based risk assessment? I am not so software savvy but I have had no regrets about jumping into 5.99 when I did, maybe a year ago.
Something like:
Cannot revert to older version so keep backups. (that should be pretty easy to know. Once I put a bunch of design work in 5.99 there was really nothing in 5.1X to back up)
Ok thanks. Just putting the idea out there. I’m not one who uses testing versions so others may or may not care about the requirement to monitor the channel.
Ok, how about a lighter touch. Put a pre-install script in the package that checks if the major version will change as a result of an upgrade from a nightly channel and ask do you really want to do this?