I know this might be a stupid question, but:
In Crashlytics I see next to my versions:
What do those numbers 31/39/43/55 means?
That's not my version codes, while 2.5.1/2.6 etc. are my version names.
In Crashanalytics number indicate new version is number of same crashes in other version too.
Related
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.
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.
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.
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.