I have an app that runs perfectly without new dependencies like this one:
A newer version of androidx.navigation:navigation-fragment-ktx than 2.4.2 is available: 2.5.0
If I upgrade to v.2.5.0, my app has warnings about unrelated elements like for example references to menu objects.
Should I wait and allow these Gradle warnings such as above notice until another upgrade comes along and try the new dependency then?
You shouldn't need to update anything unless you have a reason to. It's often a good idea (as well as new features you also get bug fixes) but it's usually not required. Specifying all your dependency versions means you get a repeatable build that should always work, so long as those versions are available
The thing about libraries is they often have dependencies on other libraries, and updating one might introduce a requirement for other stuff to be updated (which might be why you're seeing other errors appear. That broadly shouldn't happen (making things independently updateable is part of the reason for breaking everything out into separate libraries!) but here's a blog post from when they introduced it:
Starting with the AndroidX refactor, library versions have been reset from 28.0.0 to 1.0.0. Future updates will be versioned on a per-library basis, following strict semantic versioning rules where the major version indicates binary compatibility. This means, for example, that a feature may be added to RecyclerView and used in your app without requiring an update to every other library used by your app. This also means that libraries depending on androidx may provide reasonable guarantees about binary compatibility with future releases of AndroidX -- that a dependency on a 1.5.0 revision will still work when run against 1.7.0 but will likely not work against 2.0.0.
Really you have to look at the release notes for a library to see if there are any breaking changes you need to worry about. For example, here's the one for the Activity Jetpack component and if you search "dependency changes" you'll see where updating actually requires a specific minimum version of another thing
Also sometimes a library will pull in an old version of another library it depends on, so you might be explicitly interacting with a very old version of a component just because you never added it as a dependency yourself. Then if that first library requires a much newer version of that dependency, you might suddenly get a large jump that requires a bunch of changes to your code, even though it doesn't seem to have anything to do with what you updated!
PROBLEM
We have a site on Bootstrap 3.0.2 which won't compile in Codekit, it fails on things like:
floor(#grid-gutter-width / 2);
I'm guessing Less has changed but after searching, I can't figure how it's changed. Pages I've been combing through:
https://bootstrapdocs.com/v3.0.2/docs/getting-started/
https://github.com/twbs/bootstrap/releases?after=v3.1.0
https://github.com/less/less.js/blob/master/CHANGELOG.md
QUESTIONS
In general, what's the best way of handling this without breaking everything?
Does anyone know which Less changes are causing the compile errors?
Is there a version of Bootstrap 3 that works with newer Less versions?
Or would I have to somehow run an older version of Less inside Codekit?
Any pointers in the right direction would be much appreciated.
The issue was a change in Less 1.4.0 Beta 1 & 2 (2013-03-07)
maths is now only done inside brackets. This means font: statements, media queries and the calc function can use a simpler format without being escaped. Disable this with --strict-maths-off in lessc and strictMaths:false in JavaScript.
You can use the --strict-maths-off flag but I decided to plug in Bootstrap v3.3.7 and update the theme to support the newer Bootstrap (and less).
I'm trying to understand semantic versioning. Currently my module have 2 major versions as shown below.
1.0.0, 1.1.0, 1.1.1, 1.1.2
....
2.0.0, 2.1.0
So here i have copule of questions:
Found one bug in all vesions so ineed to fix that bug in all vesrions and update the vesion? or fix and update versions like 1.1.3 and 2.1.1
What if a new release has a feature and a bug fix, what should I increment?
When in doubt, the SemVer spec should always be referenced.
Say you find a bug in the following feature sets:
1.0.x
1.1.x
1.3.x
2.0.x
2.1.x
In each case, a bug fix for that feature level would look like:
1.0.x+1
1.1.x+1
1.3.x+1
2.0.x+1
2.1.x+1
Where x is the highest patch number for each of the feature sets.
Decide whether you need to support earlier versions with bug fixes. At some point, most teams limit down-level work to bug fixes and only go back two or three minor releases in each major series they still support. It's not uncommon to halt all version 1 work after one or two releases in the version 2 series.
Semver 2.0.0 #7 specifies:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
Basically, you bump either Minor or Major depending on whether you added back-compat features or made breaking changes. You can include all the bug fixes and new features you want in a single release. All lower version fields reset to zero when you bump Major or Minor.
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.