I have been publishing on biicode, using only the DEV and STABLE tags so far. Unless I have misunderstood, for a given block, it seems that I can publish a DEV version as many times as I like, and my previously published code will get overwritten by the new version each time. On the contrary, it seems that I can only publish a STABLE version once and I cannot overwrite the code published under that tag.
I was wondering how the other tags behave. Can ALPHA and BETA versions be overwritten or can I only publish under those tags just once as well?
Thanks!
Dimitri
All versions, but DEV one, are inmmutable, they are freezed after publication. The aim is to achieve full reproducibility. Changing their contents, or their tags would change what consumers of that code are effectively using. For the same reason, DEV versions, that can be overwritten, cannot be tagged.
So yes, ALPHA and BETA behave exactly the same as STABLE. Their name is just an indication for the target public The idea when you publish an ALPHA version is that you want your teams and collaborators to test it. I would tag them for example as #1.2test1, #1.2test2 and so on. BETA versions are for community testing, probable tags could be release candidates #1.2rc3, and STABLE versions are for production, you could tag them as #1.2 (and probably generate minors with #1.2.1
Note: The # is not necessary in the command, I think the actual command is
$ bii publish user/block --tag=BETA --versiontag=1.2rc3
While you can explicit it in your config file as:
user/block #1.2rc3
That should lookup it, and add also the publication index, something like:
user/block: 3 #1.2rc3
Related
Xcode 11 has changed the way that versions are handled.
So far I had two targets, Dev & Prod, each with a separate versions. Prod version would be entirely manual, Dev would be automated:
During a build, a script would run, which then would fetch git tags. One tag would contain information about the latest Dev version. If it's newer, it would update version inside Info.plist just for the Dev target
When Dev would be deployed using a script (create an ipa, resign for in-house distribution, upload), the build version would then be increased. Remote tag containing version information would then be updated
In this way everyone's dev version would get automatically synchronized and managing multiple dev builds would be be easy. Prod would be updated relatively infrequently so it can be managed manually.
However, in Xcode 11 whenver version (or build) is updated inside the General tab, entries in Info.plist are replaced with $(CURRENT_PROJECT_VERSION) and $(MARKETING_VERSION) and Current Project Version and Marketing Version inside the build settings tab is used instead.
So far I would use PlistBuddy in order to read and update versions inside Info.plist, but from what understand now I'd have to use agvtool. However, there are two issues with it:
If it's ran as a Run Script phase, it causes the build process to cancel
It is unable to handle separate versions for two targets (so I cannot just automatically manage Dev, while leaving Prod alone)
I know that theoretically I can still use Info.plist for versioning, but the moment someone changes version manually in the General tab, the whole thing will get messed up (from experience I know that this will happen).
I have two questions:
Is my understanding of the process correct?
Can still have a version management system using agvtool similar to what I had before?
I'm new in Golang, and I'm trying to develop a go-module and share it with my colleagues while I'm developing it; In JVM/sbt I used to publish my work with a 'SNAPSHOT' postfixed to version value. but How I can achieve the same in with go-modules?
Versions for modules are tagged by using repo tags (e.g. git tag), following semantic versioning (https://semver.org/).
So, any version starting with v0 is treated as unstable and may make breaking changes at any time. Once you release a v1, you cannot make any breaking changes without bumping your major version, which also means you change your module name.
You also have the option of appending +foo to the end of your version to indicate additional information about the version.
I wrote https://blog.golang.org/using-go-modules as an overview of how to get started using modules.
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.
I want to make the builds on a specific branch advance the version number in AssemblyInfo.cs files and in Package.nuspec files according to the Semantic Versioning convention (*).
In order to do this, when code is merged into this specific branch, I want to:
Ask the merging user for a new version number, preferably during merge (then run build during check-in) or when the user runs a manual build, preferably displaying a custom dialog which displays current version number and asks if API has been broken, expanded or if changes do not affect API, then save the new version number aside.
Apply version number to AssemblyInfo.cs file(s). (Related link)
Apply version number to Package.nuspec file(s).
Run build.
Publish resulting NuGet packages.
I am not sure how to get the first step working, as it is interactive.
Has anyone tried such as approach before?
Are there any known solutions?
Any tips how to solve this?
(*) Semantic Versioning convention:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
I'm currently working on Maven tools for Project Dash. One of the open issues is how to handle mistakes.
Maven central says: Nothing published ever changes. This is because Maven never tries to figure out whether a release has changed (unlike for SNAPSHOTs).
But I might have to create a new "release" of, say, part of Eclipse 3.6.2. Which version number should I use? 3.6.2.1, 3.6.2-1, 3.6.2_1, 3.6.2pl1? Why?
The convention for version numbers is major.minor.build.
major is incremented when the public interface changes incompatibly. For example, a method is removed, or its signature changes. Clients using your library need to take care when using a library with a different major version, because things may break.
minor is incremented when the public interface changes in a compatible way. For example, a method is added. Clients do not need to worry about about using the new version, as all the functions they are used to seeing will still be there and act the same.
build is incremented when the implementation of a function changes, but no signatures are added or removed. For example, you found a bug and fixed it. Clients should probably update to the new version, but if it doesn't work because they depended on the broken behavior, they can easily downgrade.
The tricky issue here is that it sounds like you are modifying code written and released by somebody else. The convention here, as I have seen it, is to postfix the version number with either -yourname-version or just -version. For example, linux-image-2.6.28-27 is a likely name of a Ubuntu kernel image.
As Maven uses dashes to differentiate between artifact coordinates, however, I would recommend (very long-windedly, apparently) to just add .version to avoid confusing it. So 3.6.2.1 in this case.
Maven project versions are specified like this.
<major version>.<minor version>.<incremental version>-<qualifier>
As you do not want to change the version number you are looking for a qualifier. I do not know if there is a general recommendation for the name of the qualifier. The Spring people e.g. did something like this
2.5.6.SEC01
2.5.6.SR02
3.0.0.M3
They didn't use the hyphen/dash notation to seperate the qualifier.
What ever you do, you have to be careful regarding the ordering of versions! Have a look at the first link I added.
Update: Also have a look at #krzyk comment for recent changes/additions.
This is because Maven never tries to
figure out whether a release has
changed
That's in my opinion not the basic reason. The reason is to have reliable builds in the future. You define the versions in your pom and that's it. If someone would remove artifacts from maven central or become worse changing an existing artifact you can't be sure that your build will be working in the future...or an older build would work.
The version number is up to you...i would suggest to use 3.6.2.1.