I have created a POC program to exercise the JCR version handling with ModeShape on both 4.0.0.Alph4 and 3.8.0.Final. The version number is increased from 1.0, 1.1, 1.2 1.3, 1.4, and etc. Then I restored the version 1.2 and made changes to it. But I noticed that the new version number is 1.3.0 now. Should the new version number be 1.2.0 (since it is based on the original 1.2) or am I missing something from the program? Thanks!
I would have expected 1.2.1, so it looks like it might be a bug. Please report the issue in the project's bug tracker. ModeShape is an open source project, we'll likely look at the issue much more quickly if you provide a simple test case.
But what we really love is a pull-request that adds to a test class one or more test methods that replicates the problem. We can get that pull-request, run the tests (which would fail), and then fix the problem. This really saves us a lot of time, and it us know that we're fixing the exact problem you see. And you'll know that the fix will be included in the next release.
Related
A lot of angular related projects use a pre-release versioning scheme of the following:
e.g. angular-cli
1.0.0-beta.22,
1.0.0-beta.22-1,
1.0.0-beta.24
e.g. #angular/material
2.0.0-alpha.9
2.0.0-alpha.9-1,
2.0.0-alpha.9-2,
2.0.0-alpha.9-3,
2.0.0-alpha.10,
2.0.0-alpha.2.0.0-alpha.11,
2.0.0-alpha.11-1,
Due to the way semantic versioning works (dot separators, numeric always lower precedence to alphanumeric parts), 2.0.0-alpha.9-experimental-pizza is still the highest version for #angular/material, even tough 2.0.0-alpha.11 is released.
Similar for angular-cli, where 1.0.0-beta.22-1 is still the highest version, even though 1.0.0-beta.24 is released.
This causes package.json dependencies with ^ versions, e.g.
"angular-cli" : "^1.0.0-beta.22-1"
to not upgrade to 1.0.0-beta.24, because 24 is a numeric version and therefore smaller than 22-1.
I also posted this as an issue to the #angular/material issue tracker here but got no response.
Is this just an oversight, or am I missing something?
Update:
angular-cli now has versions
angular-cli#1.0.0-beta.25
angular-cli#1.0.0-beta.25.1
angular-cli#1.0.0-beta.25.2
angular-cli#1.0.0-beta.25.3
etc.
So it seems this was an oversight.
Short answer is that these are manual processes. The team hasn't invested in automating them yet. At least that's speaking for the Angular CLI, since I'm a contributor to the repository source code (but not a team member).
In pretty much all recent releases, something happened at the release, so they had to issue another version. Hence things like 1.0.0-beta.xx, has been quickly followed by 1.0.0-beta.xx-1.
Some tests are hard to run before publishing the packages. Especially for the CLI which publishes a range of packages not just one (a couple webpack plugins that the CLI uses are available as separate packages for other non-CLI seed projects to use).
Usually when the team is happy with a version, they explicitly tag it as latest, which is something npm allows publishers to do, so, you shouldn't in theory have this Angular Material alpha 9 vs alpha 11 problem, unless alpha 11 is not tagged as latest or something.
Long time later, I think it was an oversight in the alpha / betas. This is now resolved and angular projects follow semver also for the pre-release tags.
It looks like I can use:
//getbootstrap.com/dist/css/bootstrap.css
//getbootstrap.com/dist/js/bootstrap.js
to automatically use the latest version of bootstrap.
Does anybody ever do that?
You have CDN's that have a similar functionality (BootstrapCDN for example), but I wouldn't recommend to automatically get the latest version. If the new version breaks something you wouldn't know it until it's too late.
Besides, what would the benefit be? Anything major is very likely to break something, and anything minor is, well, minor.
At http://getbootstrap.com/, they say
"Downloads are pulled directly from the latest committed code on
GitHub, and as a result our docs may at times be out of sync."
Your page will load faster if you get your bootstrap from their site but it may be outdated.
Hope it helped!
Some months ago I installed Lazarus 0.9.28 + FPC 2.2.4 to work on a new project. Some time after it I ran into some bugs related with image loading on a TImage. After googling a bit I found some information pointing to the fact that the bugs I was facing were already solved in a later version of FPC (can't remember the link now).
So I decided to download and install a newer version. This was around January and the latest stable version was not released yet, so I choose to install the snapshot Lazarus 0.9.31-29128 + FPC 2.4.2-2011-01-20. I opened my project with the new IDE and compiled it.
Luckily the bugs I faced were gone, but I have run into an IDE (?) one. After the upgrade, when I am on the code tab of some of my forms I do not see the code formatted. Instead I only see plain text, like this:
But on some forms I see the code formatted correctly, like this:
Anyone has run into this before? If yes, could you solve it and how? Or can anyone tell me what the correct way to upgrade a Lazarus project between versions is?
It is more of a nuisance than a real problem but still I would like to solve it. Any help would be appreciated.
EDIT
I noticed that in the forms where the code shows correctly highlighted the LCLVersion in the .lfm file is 0.9.28.2, while in the forms where the code shows like plain text that property in the .lfm file is 0.9.31. Could have something to do with the problem? I tried changing the value but it did not change anything.
Thanks in advance and best regards
I don't know if this is actually causing your problem, but Lazarus keeps a set of settings in application local. ($user\AppData\Local\lazarus on my vista).
This config dir is not erased upon deinstallation, and the new installation will reuse this.
In case of strange problems, remove the config dir, and let the current installation generate a new one.
I love the maven-versions-plugin but sometimes I forget to run it for a while. Is there a way to make a maven build fail (and thus have a continuous build fail) when certain important dependencies are out of date?
I think you're approaching this incorrectly. Mail yourself the output of the maven-versions-plugin if you want, but don't fail the build due to changes outside of your control.
Even more, why would you want to needlessly update to the latest versions? I have seen many tricky problems appear due to upgrades which have brought slight changes to previous behaviour.
This, in general, is a bad practice - to update versions automatically. There is no practical reason of using the latest version of any package. If the library you're using satisfies your requirements you should stay with this version for security/stability reasons. And forever.
I think that maven-versions-plugin is an anti-pattern itself.
ps. When and if you want to do integration testing of modules developed by different teams/programmers, it is "integration testing". Even in this case I still think that on-fly version updating is the wrong approach. Root project should not do this integration testing, instead, every sub-module (or JAR, in your case), has to be responsible for integration testing of itself together with the rest of the system. When a sub-module increases its version it has to validate whether everything is still fine, and only then has to release a new version to the repository. And when the sub-module is doing the validation it has to be dependent on statically specified version numbers.
I'm looking for a version numbering scheme that expresses the extent of change, especially compatiblity.
Apache APR, for example, use the well known version numbering scheme
<major>.<minor>.<patch>
example: 4.5.11
Maven suggests a similar but more detailed schema:
<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732
Where is the Maven versioning scheme defined? Are there conventions for qualifier and build number? Probably it is a bad idea to use maven but not to follow the Maven version scheme ...
What other version numbering schemes do you know? What scheme would you prefer and why?
I would recommend the Semantic Versioning standard, which the Maven versioning system also appears to follow. Please check out,
http://semver.org/
In short it is <major>.<minor>.<patch><anything_else>, and you can add additional rules to the anything else part as seems fit to you. eg. -<qualifier>-<build_number>.
Here is the current Maven version comparison algorithm, and a discussion of it. As long as versions only grow, and all fields except the build number are updated manually, you're good. Qualifiers work like this: if one is a prefix of the other, longer is older. Otherwise they are compared alphabetically. Use them for pre-releases.
Seconding the use of semantic versioning for expressing compatibility; major is for non-backwards compatible changes, minor for backward-compatible features, patch for backward-compatible bugfixes. Document it so your library users can express dependencies on your library correctly. Your snapshots are automated and don't have to increment these, except the first snapshot after a release because of the way prefixes are compared.
Purely for completeness, i will mention the old Apple standard for version numbers. This looks like major version. minor version. bug version. stage. non-release revision. Stage is a code drawn from the set d (development), a (alpha), b (beta), or fc (final customer ship - more or less the same as release candidate, i think).
The stage and non-release revision are only used for versions short of proper releases.
So, the first version of something might be 1.0.0. You might have released a bugfix as 1.0.1, a new version (with more features) as 1.1, and a rewrite or major upgrade as 2.0. If you then wanted to work towards 2.0.1, you might start with 2.0.1d1, 2.0.1d2, on to 2.0.1d153 or whatever it took you, then send out 2.0.1a1 to QA, and after they approved 2.0.1a37, send 2.0.1b1 to some willing punters, then after 2.0.1b9 survived a week in the field, burn 2.0.1fc1 and start getting signoffs. When 2.0.1fc17 got enough, it would become 2.0.1, and there would be much rejoicing.
This format was standardised enough that there was a packed binary format for it, and helper routines in the libraries for doing comparisons.
After reading a lot of articles/QAs/FAQs/books I become to think
that [MAJOR].[MINOR].[REV] is most useful versioning schema to
describe compatibility between project version (versioning schema
for developer, does not for marketing).
MAJOR changes is backward incompatible and require changing
project name, path to files, GUIDs, etc.
MINOR changes is backward compatible. Mark introduction of new
features.
REV for security/bug fixes. Backward and forward compatible.
This versioning schema inspired by libtool versioning semantics and by articles:
http://www106.pair.com/rhp/parallel.html
NOTE: I also recommend provide build/date/custom/quality as additional info (build
number, build date, customer name, release quality):
Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545
But this info is not versioning info!
Note that a version number scheme (like x.y.0 vs. x.y) can be constrained by external factors.
Consider that announcement for Git 1.9 (Januaury 2014):
A release candidate Git v1.9-rc2 is now available for testing at the usual places.
I've heard rumours that various third-party tools do not like the two-digit version numbers (e.g. "Git 2.0") and started barfing left and right when the users install v1.9-rc1.
While it is tempting to laugh at them for their sloppy assumption, I am also practical and
do not mind calling the upcoming release v1.9.0 to help them.
If we go that route (and I am inclined to go that route at this moment), the versioning scheme will be:
The next release candidate will be v1.9.0-rc3, not v1.9-rc3;
The first maintenance release for v1.9.0 will be v1.9.1 (and Nth one be v1.9.N); and
The feature release after v1.9.0 will be either v1.10.0 or v2.0.0, depending on how big the feature jump we are looking at.