taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Taler releases


From: Christian Grothoff
Subject: Re: [Taler] Taler releases
Date: Mon, 17 Jun 2024 21:23:54 +0200
User-agent: Mozilla Thunderbird

Hi Slack Coder,

Well, someone *tagged* those releases in Git, but I never build those TGZ myself and thus also never even tried to upload them ;-). Not sure why they were tagged either, it seems Florian did both, maybe to test something else. But, anyway, not an upload failure :-).

Florian: did you intend to upload those? Or were they just tagged for local deployments?

Happy hacking!

-Christian

On 6/17/24 20:38, Slack Coder wrote:
  Hi Christian,
First of all, thanks for alerting me that my FTP upload didn't work, I used a new script to publish the source TGZ and it seems to have (silently) failed on me. I'll need to investigate this, I thought I did publish some 0.11 release TGZ on ftp.gnu.org, but clearly I failed :-(.

A heads up just in case, the latest merchant (0.11.4) and libeufin (0.11.3) source tarballs from eight days ago did not make it to the mirror either.

Anyway, aside from that, the main things to know:

x.y.z

if x=0: pre-production development releases, maybe suitable for regional- or event currencies, but probably not for regulatory-compliant production systems. No warranties, check the bug tracker, etc. :-).

y: feature-based milestone, when all components have reached the milestone, we'll announce the release.

z: minor release per component, used to make minor releases with bugfixes or new features after a release, and also to make pre-releases for testing before the release announcement.

None of these are at all indicative of *protocol* compatibility: for that we have the protocol versioning MAJOR:MINOR:AGE with colons (see https://tutorials.taler.net/merchant/versioning).  In general, we introduce new features but will remain compatible with *several* protocol versions back and only drop compatibility when we're pretty sure that nobody we're aware of is still using ancient code. So no _need_ to check for versions in general. Exceptions may apply, especially for x=0 and isolated features, but we try very, very hard to avoid those already.

So basically, if you want the features of release y, use all components of y otherwise you might not get the features. Of an individual component we may at any time make improvements by bumping z. Don't worry at all about having z differ between components, it is *normal*.

Once x>0, we'll kind-of use SEMVER where x indicates major new developments and y indicates fully compatible changes and z minor patches, but *still* we cannot ever expect everyone to update to a new version at the same time, so we *must* always be compatible to x +/- 1 version *at least*. For details, the only way to know is to check the protocol versioning (/config endpoint) for the respective component via MAJOR:MINOR:AGE as explained in the video-tutorial linked above.

I hope this helps!
Yes it did, thanks!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]