Should we have a daily build?

[bricelam]

I'm not sure how important this is given there's almost no code in this repo.

But if we want to, we should use

• GitHub Actions for automated daily builds
• GitHub Packages as a NuGet feed
• Nerdbank.GitVersioning for automatic versioning

[utelle]

I'm not sure how important this is given there's almost no code in this repo.

IMHO daily builds would be overkill. I usually release new versions of SQLite3 Multiple Ciphers shortly after the release of a new SQLite version. This happens typically 3 to 4 times per year - sometimes there are SQLite3 bug fix releases inbetween, especially, if major new features were added. And of course I make new releases, if bugs had to be fixed in the encryption extension.

I don't expect many changes in this repo ... but I may be wrong.

But if we want to, we should use

• GitHub Actions for automated daily builds

As said I don't think we need daily builds. However, a GitHub action that can be triggered manually to build a new release would be a good thing.

• GitHub Packages as a NuGet feed

I haven't used GitHub packages up to now. So, if they can be configured as a NuGet feed, that sounds like a good idea. However, maybe @jammerxd has other proposals how new NuGet package versions should be published.

• Nerdbank.GitVersioning for automatic versioning

I haven't used that tool yet, but automatic versioning may be a good idea. Maintaining version numbers manually can be a pain.

[bricelam]

We should close this. I agree it's overkill.

a GitHub action that can be triggered manually to build a new release

The existing action can be used for this. It runs for every commit to main and the packages should be upload-ready.

Maintaining version numbers manually can be a pain.

I do a mix. Sometimes the automation can be a pain too.

[jammerxd]

Yeah I agree that daily is a bit overkill for this. Automatic versioning I could go either way, my recommendation would be to version our packages based on the sqlite version (I got annoyed looking through the Microsoft sqlite package trying to find which version of sqlite it was based off of)

[utelle]

Automatic versioning I could go either way,

I'm fine with doing it manually. However, currently the version number is referenced from 3 places:

1. Directory.Build.props
2. Tests/Tests/Tests.csproj
3. Tests/Tests/MauiTestApp.csproj

It would be preferrable to have a single place where to adjust the version number, if that is possible.

my recommendation would be to version our packages based on the sqlite version (I got annoyed looking through the Microsoft sqlite package trying to find which version of sqlite it was based off of)

I fully understand that it can be annoying to find out which version of SQLite is used under the hood. However, using the SQLite version number makes it difficult to number interim releases of our packages. For SQLite3 Multiple Ciphers itself I use annotated version tags, that is, I add a short message to each version tag: based on SQLite3 x.y.z. This allows users to identify the underlying SQLite version easily.

That said, I agree with @bricelam that we use a separate version number, starting with 1.0.0.

[bricelam]

Yes, I want to get the version out of the test projects. I also want to add a test to validate the other two versions.

[utelle]

Yes, I want to get the version out of the test projects.

That would be great. 😃

I also want to add a test to validate the other two versions.

Ok. How do you plan to do that?

Regarding the versioning I have a question. At the moment the version is specified as 1.0.0-rc.1. What will be the criteria to move from release candidate to official release? Should the release candidate be published on NuGet.org? Or only the official release?

[bricelam]

I also want to add a test to validate the other two versions.

Ok. How do you plan to do that?

I'm going to flow the version in from MSBuild (the .props/.csproj files) to C# then check that they match sqlite3mc_version() and sqlite_version().

What will be the criteria to move from release candidate to official release?

After we publish, I'm going to write a blog post and promote it on social media so people can try it out. I'd give users a week or two to report any major bugs then release it as GA. But we could also just go straight to GA if you want.

Should the release candidate be published on NuGet.org? Or only the official release?

Prereleases are perfectly acceptable on NuGet.org they give users an easy way to try it out and report any issues. NuGet won't automatically upgrade anyone to a prerelease unless they tell it to. Some projects even put daily builds on NuGet.org, but that's overkill IMHO and should be through things like GitHub Packages or MyGet.

[utelle]

I also want to add a test to validate the other two versions.

Ok. How do you plan to do that?

I'm going to flow the version in from MSBuild (the .props/.csproj files) to C# then check that they match sqlite3mc_version() and sqlite_version().

Sounds good.

What will be the criteria to move from release candidate to official release?

After we publish, I'm going to write a blog post and promote it on social media so people can try it out. I'd give users a week or two to report any major bugs then release it as GA. But we could also just go straight to GA if you want.

Let's start with a release candidate. Waiting for feedback for a couple of weeks before making the first GA release is a good idea.

Should the release candidate be published on NuGet.org? Or only the official release?

Prereleases are perfectly acceptable on NuGet.org they give users an easy way to try it out and report any issues. NuGet won't automatically upgrade anyone to a prerelease unless they tell it to. Some projects even put daily builds on NuGet.org, but that's overkill IMHO and should be through things like GitHub Packages or MyGet.

Thanks for the clarification.

BTW, I saw that Eric's SQLitePCLRaw is still based on older versions of SQLite (3.41.2) and SQLCipher (4.5.2), while the current versions are 3.44.0 resp 4.5.5. I usually try to keep SQLite3 Multiple Ciphers more or less in sync with SQLite, and I intend to do the same with the NuGet packages.

[bricelam]

I saw that Eric's SQLitePCLRaw is still based on older versions of SQLiteand SQLCipher...I usually try to keep SQLite3 Multiple Ciphers more or less in sync with SQLite.

Ha, Eric's a busy guy. I would say that he tries to keep up to date too. It usually takes users pestering him for a while over useful new features to make it a priority.

The more up to date, the better!

[jammerxd]

I fully understand that it can be annoying to find out which version of SQLite is used under the hood. However, using the SQLite version number makes it difficult to number interim releases of our packages. For SQLite3 Multiple Ciphers itself I use annotated version tags, that is, I add a short message to each version tag: based on SQLite3 x.y.z. This allows users to identify the underlying SQLite version easily.

That said, I agree with @bricelam that we use a separate version number, starting with 1.0.0.

As long as we make it obvious which version of sqlite we're packaging under the hood.

[bricelam]

PR #5 adds the following to the package description.

Includes SQLite3 Multiple Ciphers 1.7.2, based on SQLite 3.43.2.

[utelle]

As long as we make it obvious which version of sqlite we're packaging under the hood.

PR #5 adds the following to the package description.

Includes SQLite3 Multiple Ciphers 1.7.2, based on SQLite 3.43.2.

We have these version numbers now mentioned in the package description and the README.

@jammerxd Is this sufficient? Is it sufficiently visible? Or do we need to emphasize it more?

[utelle]

I saw that Eric's SQLitePCLRaw is still based on older versions of SQLiteand SQLCipher...I usually try to keep SQLite3 Multiple Ciphers more or less in sync with SQLite.

Ha, Eric's a busy guy. I would say that he tries to keep up to date too. It usually takes users pestering him for a while over useful new features to make it a priority.

Regarding the versions used by SQLitePCLRaw: SQLite 3.41.2 was released in March 2023, SQLCipher 4.5.2 (based on SQLite 3.39.2) was released in August 2022. Both experienced 3 updates in the meantime.

The current package System.Data.SQLite 1.0.118.0 (which is maintained by the SQLite development team) is based on SQLite 3.42.0. That is, it also lags behind roughly half a year.

So, the .NET users are probably used to such delays.

The more up to date, the better!

As said I usually try to make releases shortly after the release of new SQLite versions.