I'm working with the SDK for the first time, encountering the following problem ...
I've got a simple module, just using Gateway. When I run my Ant file to deploy, I get the following ...
I confirmed the server's accessible from the URL, no problems there. When I jump onto Gateway's Console, I see the following error logged ...
I've got module.xml defined as follows ...
I'm assuming that the error's referring to the version I've got specified not being a numeric value. Is this correct? Can I propose this restriction be lifted?
rc and beta are just permitted phrases, everything else is numeric.
I don’t think it’s in the documentation anywhere, which is our mistake. I’ll add a blurb about it to the SDK docs for the next release.
There’s a poorly documented Version class in ignition-common with parse(String) and toParseableString() methods that expect this format. It’s used everywhere in Ignition for versions, including in the module system when comparing a module being installed or upgraded to the existing version of that module, which is one place the ability to compare them becomes important.
What we try to do when versioning our modules is:
major is what it is.
minor matches the Ignition platform version
revision is for small releases, bug fixes, “point” releases
So a module for Ignition 7.3 might be 1.3.0 and increment 1.3.1, 1.3.2, 1.3.3 with bug fixes. Then when 7.4 is released that version would likely change to 1.4.0. Sometime down the line maybe the module is totally revamped (like what happened with Vision) or something significant enough happens that it warrants a bump in the major version. Now it’s 2.4.0, 2.4.1, etc…
The build portion, at least for us, comes from version control. Changesets increment that build number.
Ah, thanks for clarifying. Just for future reference by others, the Version class is within com.inductiveautomation.ignition.common.model.
We’ve had a desire to start assigning version numbers using Semantic Versioning; however, being restricted to just the beta and rc phrases hinders us from fully using this specification … perhaps there’s a feature request hidden in this reply somewhere?
I had a question today, was wondering if you’d be able to help. We use Mercurial for version control. With every changeset, the revision number increases. I noticed with your version numbers, the build’s are all at a reasonable number. How do you handle the build number when shifting between versions?
With my environment, our build numbers are populated with the revision of the repository branch we’re working upon. We can adjust the major/minor/revision numbers manually in our build.properties file. If we wanted to “reset” our build number, we’d have to clone the repository/start a new repository, (at least as far as I know); however, that has it downsides. I was just curious if you guys encountered a similar scenario on your side and could provide any tips.
I know they reset their version number back to 1 when they switched from SVN to GIT. I’m guessing that under GIT there are less commits to the trunk and thus the lower version/build number.
If you look at the archived versions of Ignition you will see much higher build numbers.
Another scheme I have heard of is the daily build server updates the build number only on a successful run (build/test). In this case the build number is not tied to the version number at all.
So what we do is we clone repositories for major versions (7.3 and 7.4 are in separate repositories). Every few weeks or so, we push changes from the 7.3 repository to the 7.4 repository and merge the changes as needed. That way, the 7.4 repository has its changes and the 7.3 changes together in one place. Then we grab the highest revision number when building (we always build from the tip), and that become the build number.
[quote=“Robert”]I know they reset their version number back to 1 when they switched from SVN to GIT. I’m guessing that under GIT there are less commits to the trunk and thus the lower version/build number.
If you look at the archived versions of Ignition you will see much higher build numbers.
Another scheme I have heard of is the daily build server updates the build number only on a successful run (build/test). In this case the build number is not tied to the version number at all.[/quote]
We use Mercurial, not Git. (I wish we used Git though )
)