Still learning gradle here. Looking for a way to get either the latest "anything" (snapshot/integration or release) or latest must-be-release for a given range, say [1.0,2.0). Is there a way to specify that? Searched everywhere and only found references to either using ranges (which does not seem to allow me to restrict to releases or work with snapshots) or to always keep it entirely open using "latest.integration" and/or "latest.release".
Please help!
[1.0,2.0) already means either "latest anything" or "latest must-be-release" (I think the latter, but not entirely sure). The other isn't currently supported.
OK, I just updated to the newest Gradle 2.1. That resolved some issues I was having. Otherwise, I discovered the following:
"latest.integration" will match the latest anything - snapshot or release, whatever it finds newer.
"latest.release" will match the latest release and skip the snapshots.
"major.minor.+" (however many version number segments you have) will actually behave as "latest.integration" restricted to major.minor. Originally I thought it was restricted to releases but, no, it actually matches snapshots too.
"[1.0,2.0)" will actually behave list "latest.integration" within the range, too and will include snapshots, unlike I thought and commented above.
So, what I now don't know how to do is how to restrict a range or "1.+" to releases, but that is not my immediate problem (may be some hours from now, LOL).
UPDATE
One way to restrict versions to a range seems to be to mess with "Component metadata rules". Non-matching versions (those outside range) could be artificially declared non-releases. This is really ugly, though...
UPDATE 2
A part of my confusion was due to behavioural change between the old Gradle I was using and the new 2.1 one. Above is for 2.1 - old one I had (1.8) did NOT behave cleanly as per above.
Related
I added a single method definition in a interface and I am getting a baseline error with a suggestion asking me for a major version change. I want to ask how does it calculate whether a major or minor change is required? adding one line method declaration shouldn't be a major change, right?
Is there a way to tell it to ignore this particular method declaration?
A new method in an interface means that none of the current implementors are compatible with this version of the interface. Before they become compatible again they will have to implement the new method, thus the version bump is justified. Don't game around it, combine it with more changes or just accept that the bundle version of volatile bundles increases quicker than your version stamp on the fully packaged software.
There's nothing bad to version bumps
I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
Let's say you have a bunch of code and let's assume that you have a first working version. This is version 1.0. You go to your git repository and tag the version. Then in that exact moment you have your first tag or release. Then you have in your code version number 1.0 and in your repository tag number 1.0.
My question is, when exactly do you change the version number in the code to version 1.1 (let's assume we don't care about 1.0.1):
A) do you change it right away after the tag 1.0 is done? Therefore all your code from this moment on belongs to version 1.1. This version "ends" when you create a new tag 1.1, which is the stable version 1.1 and change to version 1.2 in the code.
B) do you change it after you have done several code changes and publish your second tag (tag 1.1)? In that case you have a tag version 1.0 of the stable code and you are making improvements in the code. All new changes you do belong to version 1.0. Then when you are finished making changes, you change the code number to 1.1 and the tag number to 1.1
Nerdy question right ;-)
This is somewhat subjective but I would strongly suggest A. Branch out at a the time of release and start working in a new branch.
It's because your users are then in sync with where you left off in v1. If you introduce a number of features for the working v1.1 branch and possibly some design changes which kind of strongly branch away from v1, you can always come back to what the users are seeing by updating to the v1 branch.
Branching in this way based on release is useful as "checkpoints" based on what the users actually have, not based on what you intend to deliver. This way when a user reports something, you can easily know which version of the code they're actually using and quickly flick to it.
This also leaves some breathing room to do easy "service patches", like a v1.01. I know you wrote that you don't care about that, but if your users report an issue in v1 that you've already kind of solved in v1.1 or the v1.1 design has changed in a way to make it no longer valid, but you want to sneak some patch in between there, you can update to your v1 branch, make a minor tweak, and release a v1.01 service patch kind of thing. There's a bit more wiggle room there for that kind of thing.
As a hypothetical, imagine a user reports a glitch in v1. You can't reproduce it in your latest development branch. Now does the fact that you can't reproduce it in your current changeset mean it's fixed, or that you simply can't reproduce it? The easiest way to know for sure is to be able to quickly switch and use the same version you released to the user. That's where branching off and kind of freezing the branch at the time of release is useful.
Of course you could do that without branching or tagging at all if you just comment your changesets in a way such that you know which one is which. But then there's little point to tagging/branching in the context of a release. If you do it as an organizational means and a way of isolating changesets to one place, I'd suggest doing it in a way that keeps those branches in sync with what the users actually have.
Recently we upgraded our SONAR from 3.x to 4.3. There was an error in our Jenkins build (squidindex was null) which triggered the upgrade of the java from 2.2 to 2.2.1 along with the plugins for JaCoCo, Findbugs, Squid for Java, and Surefire.
Once SonarQube was up and running again, we discovered that although no code changes had taken place, we now had over 200 critical issues as well as a high number of major ones. Upon research, it became apparent that all of our previously marked false-positives had now reappeared.
Obviously we want to find a way to fix this besides walking through over a thousand various issues and re-marking them.
We have done some research in the database and have discovered a puzzle that we think might be related. In the Issues table, we have found that there are duplicate entries where the first difference is that one entry has the simple file name and the other entry has the file name along with the extension.
(I had an image of a few lines from the database to put here, but as I do not yet have a 10 reputation, I cannot. Please contact me and I will be glad to email the image. Sigh.)
As you can see, Lines 2 & 3 both refer to line 134 in the file PersistentObjectCollection.java. Line 2 shows that the issue is FIXED and CLOSED while Line 3 shows the same issue as Open and null resolution.
We are wondering if we could safely use SQL to find matched pairs like this and copy the necessary columns across to register the issues properly?
Can you please take a look and tell me if this is something feasible to do, or if there is a better alternative to try.
Question already asked on the SonarQube mailing list : http://sonar.markmail.org/thread/kpx3une24lwoilli
Please don't duplicate question !!
I'm using both scrollTo and the "child"-plugin serialScroll quite frequently, and like them because they
Actually SCROLL things, rather than animating css-properties (margin/position etc)
Are flexible and can be used in many different situations, unlike lots of other scroller/sliders that adds a bunch of bells and whistles that you don't really need.
Thing is, the plugins haven't been updated since 2009, and although they still work just fine, regardless of jquery version, there are things that could need improving (like the ability to change settings after initilaisation), and overall it doesn't fell optimal to use a 3 year old plugin, solid and stable as it is.
Does anyone have a suggestion of other plugins that might do the same thing, perhaps better?
http://flesler.blogspot.se/2007/10/jqueryscrollto.html
This is an old question, but for the record, as Shauna said, the plugins aren't outdated, OP might have been looking at Google code hosting which is indeed out of date.
The plugin is now hosted on Github. There's no much of a need to update it too often given it's very stable already, but I do land some commits every now and then when needed.
I don't have a suggestion for anything better (even Google is coming up with Flesler's plugin or hand-written from base JavaScript or jQuery), but Flesler is still updating the plugin. You can find the latest version in GitHub.