APIs and libraries should tell us much more about their semantics so that we can assert compatibility directly rather than relying on a number
CalVer: Calendar Versioning
51–60 of 102 posts
Re: CalVer: Calendar Versioning
#52Earlier quoted context omitted.
Not sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.
what would be a more reliable way to know?
Look at the following:
- Number of commits.
- Number of open issues.
- Number of closed issues.
- How they respond to issues.
- Are the commit messages descriptive?
- Is the codebase a mess or does it look reasonable?
Re: CalVer: Calendar Versioning
#53Re: CalVer: Calendar Versioning
#54I thought this was a new team calendar that was version controlled when I first read the headline. And now I want that.
I had exactly the same thought, it's kind of an interesting idea. I'm not 100% sure what the usefulness is though.
I suppose it depends on how much content you put in your calendars, but I agreed with you on the usefulness, at first.
Then I thought about how meeting requests are basically PRs. How how easy it could be to create shared calendars using submodules and such.
Re: CalVer: Calendar Versioning
#55Any opinions on calver vs semver for, say, open source projects or APIs/SDKs?
Semver is used for regular releases when you need to communicate deeper information to multiple consumers. A library version usually needs to communicate lots of information, to developers, to users, to distributions. Maybe this release is a dev release, while this other is stable, this release is LTS while another is not, this release has breaking changes, this one doesn't, etc.
Calver is used when you don't care about anything but the temporal difference between releases, and you can basically toss any expectation of compatibility between versions, other than something temporal ("this version is compatible with previous versions for up to one year"). That's why APIs use it.
Generally speaking, OSS uses Calver when the releaser doesn't need to care about the consumer, compatibility, etc. You'll find Linux system packages using Calver when someone basically cloned a random Git repo, made a one-off build, and decided "this will be a release" (you find this with firmware a lot), or as a way for 3rd parties to fork an official version with patches.
Random assortment of Ubuntu packages with a variant of Calver (sometimes along with Semver): libargon2, gyp, aspell, language-pack-en, libcrystalhd3, ntfs-3g, x11proto-* , python-cliapp, net-tools, rtmpdump, iputils-*, dh-python, amd64-microcode, lsb-release, libstring-escape-perl, wireless-regdb, ubuntu-keyring, tzdata, fonts-vlgothic, usb-modeswitch-data, publicsuffix, autotools-dev, geoip-database, ca-certificates, dns-root-data
Re: CalVer: Calendar Versioning
#56I thought this was a new team calendar that was version controlled when I first read the headline. And now I want that.
I also wish all of my data was version controlled, which is why when I created EteSync[1] I made sure to include a full change history. Check it out, I think it's exactly what you're looking for, and it's fully open source, so you can host in on-site if your company requires that. https://www.etesync.com
I will take a look! I'm looking to further distance myself from Google and such this year, so this is very timely.
Re: CalVer: Calendar Versioning
#57I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…
High major numbers with semver is a "stay far far away" signal for me; each major increment is a non-backwards compatible change.
Re: CalVer: Calendar Versioning
#58I thought this was a new team calendar that was version controlled when I first read the headline. And now I want that.
I also wish all of my data was version controlled, which is why when I created EteSync[1] I made sure to include a full change history. Check it out, I think it's exactly what you're looking for, and it's fully open source, so you can host in on-site if your company requires that. https://www.etesync.com
Can that do shared calendars? (I know that's technically challenging with ETE encryption). If it does, I will drop my self-hosted davical for it in a heartbeat.
Re: CalVer: Calendar Versioning
#59I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning. Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31 . These versions tell you nothing about the projects except their release dates. On the other hand, semantic versioning (w…
Not sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.
yeah is 1.7 a very stable 1.x or a very immature 2.x? what is 0.7 then? and 2.0?
can't answer one and the other consistently.
it's great for compatibility level, and that's that.
Re: CalVer: Calendar Versioning
#60Earlier quoted context omitted.
I also wish all of my data was version controlled, which is why when I created EteSync[1] I made sure to include a full change history. Check it out, I think it's exactly what you're looking for, and it's fully open source, so you can host in on-site if your company requires that. https://www.etesync.com
Can that do shared calendars? (I know that's technically challenging with ETE encryption). If it does, I will drop my self-hosted davical for it in a heartbeat.
I found this in the FAQ:
If I want to share a calendar with my spouse, do I need to get two subscriptions? No. You can just create a normal subscription for yourself, and an "Associate" subscription for your spouse. Then share the calendar with the second account, and that's it. However, Associate accounts can't create their own calendars. So in order to have a personal calendar (that you can't see), your spouse will have to get a normal subscription too.