Related
Good evening friends,
I am looking for a python library of Fuzzy ARTMAP(Adadptive Resonance Theory),but the ones I find don't work well or I don't know how to use them.
Another option would be to find a Fuzzy ARTMAP code written manually, it would be of great help.
I started using a few general purpose utility packages which I integrate into my projects with composer via packagist. A good one I found is jbzoo/utils:
https://github.com/JBZoo/Utils
It has a group of classes with useful methods. I see that some packages have useful methods that others don't, so I created my own package in which I combine the useful classes and methods of various packages, and also add my own methods. I don't have time to setup tests and meet the requirements to become a contributor on github, but it would be great if I could collaborate with others in building packages like this.
Is there a system where users collaborate in building packages in a wikipedia style fashion where anyone can go in there and make improvements and pitch in whatever they want in an open and free way? For example, I could add a few new methods, then the next programmer might take a look at the methods, see some potential problems and improve the methods. Another programmer may decide to spare a bit of time to write up tests for the methods and classes written by the previous programmer etc.
I realise this comes with some big security risks, but again, using wikipedia as an analogy, most people who use it, use it with the right intentions and the result is wikipedia is a relatively trustworthy source of information. I assume the same principal would apply to this.
Is there a system like this? It would of course be ideal if you could install the packages with composer (or whatever package manager for whatever language the package is written in).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Suppose I have a web application with some basic functions. I want to market it. So I would like to assign a version number - something like 0.0.1. What I want to know is are there any constraints that should apply to that numbering system?
Hope you understood my question, thanks in advance.
Most places use something like this:
Major Release.Minor Release.Hot Fix.Build
Your version numbers would look like 1.5.0.15, etc.
A lot of free software uses a three point system: X.Y.Z where
X is for compatibility breaking releases.
Y is for other releases, with even numbers being stable and odd numbers being unstable.
Z is for fixes.
This way version 0.28.1 is a stable release with one fix and 2.9.0 is an alpha release with zero fixes.
Some people also have fun developing their own schemes. E.g. Tex which by each release approxed Pi, with version numbers: 3, 3.1, 3.14, etc.
It does not really matter, as long as you can use the version number to identify your versions (i. e. either add your source control system's internal revision number into the version number) or use it for tagging your releases.
When you do so, you might want to use that number as your third (or fourth) component. It looks confusing if some product jumps from version 1.12345 to 2.12346, but jumping from 1.4.12345 to 2.0.12345 is more common.
About which number to start, I just want to quote Eric S. Raymond:
In the closed-source world, Version
1.0 means "Don't touch this if you're prudent."; in the open-source world
it reads something more like "The
developers are willing to bet their
reputations on this."
You can use whatever numbers you want in your versioning - who's going to constrain you?
If you want your first version to be 0.0.0.0.0.0.0.1, that's fine, albeit a little silly. If you want your first version to be 106.3, you can do that too, but that's a little more ridiculous.
Check out the Wikipedia article on Software Versioning for some tried-and-true ideas of realistic version numbering schemes.
I've always used (rewrite).(feature added).(bug fix).
But set your own rules and make them public so your users understand them.
Take a look here. python setuptools has a very interesting and clear specification for version numbering. I'm sure you can obtain some very insightful hints from it.
To the best of my knowledge, there is as yet no government agency dictating how you number versions. But don't worry, I'm sure it will come soon enough.
Ditto on those suggesting major-dot-minor-revision. My general approach is: Major changes get a new major version. Like, if we've added important new features. Small changes, like added some little convenience features or one new report, get a minor revision. Hot bug fix changes get a revision.
I would definately avoid calling your first published version "0.l" for simple marketing reasons: Numbers less than 1.0 sound like a preliminary version or a beta version. I've known people to call their first version 2.3 or some such just to make it sound like it's been around a little while to inspire more confidence, though that strikes me as a little dishonest.
how about the software which is not distributed to public like a webmail source code? do you think that the build or bug fix number is still important in this case?
10.50.1600.1
major.minor.build.revision
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.
eg. In SQL server 2008 RTM version number is 10.00.1600.22 and In SQL server 2012 version is 11.00.2100.60
First field is changed due to change in project name i.e. 10 and 11
In SQL server 2008 R2 RTM version number is 10.50.1600.1 and In SQL server 2008 version is 11.00.1600.22
Second field is changed due to introduction of new features.
Third field indicate build(developed)
Forth field indicates revision i.e. hotfixes applied...
You might want to start by taking a look at the Software versioning article on wikipedia, which gives some informations about the possibilities you have ;-)
It might give you some ideas of what you could do in your specific case...
I've used
Major.Minor.Release.Build
1.02.4.15
and also
Year.Month.Date
2009.12.10
but anything that allows you to individually track releases would work. As long as you're consistent.
We use major.minor.revision.build where revision is the SVN revision and build is the build number which is based on the current date (in YYDDD format where YY is the year and DDD the day number, so 18001 would be Jan 1st 2018.)
Having the SVN revision is incredibly useful and has saved us on more than one occasion.
Version numbers are not a concrete specification in software development.
In other words, one team may use 1.0.0.0, others may use 1.0.0 and so on. It matters not.
Just choose something that works for you.
Typically major.minor.revision is the most simple and straight forward method to use. Visual Studio for example can assign version numbers automatically for you, as can other tools. So all you are required to update is the major/minor values. The build/revision numbers are updated automatically.
I seem to remember that in the old days (I am talking Commodore here) we used a syntax like
release.version.revision
which could be appended with either fix and/or build, where fix would usually be a letter stuck directly to the revision. So a full number would read something like:
2.1.44a.786
But like most have already said, it doesn't really matter, there is no true standard for this. Just use whatever is most convenient for you.
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!!
You can use any form of version numbering you desire.
I just recommend using something that makes sense. The Major.Minor.Revision numbering is popular, but any numbering scheme you wish is "valid".
When developing software libraries, I recommend using the version number to communicate the level of source and binary compatibility between two releases.
Since you're developing a web application, a two part version number is probably sufficient. The first part is for new functionality and the second is for fixes.
Can someone recommend a source control product that does all of the following:
Seamless integration into VS 2008 Pro
Will allow me to create different "editions" of a program (like "express" and "pro") - maybe with branching?
Will allow me to track changes for specific client requests. Say I have four clients, 2 on express, 2 on pro. I would be able to create specific, customized changes for all clients while still maintaining a singular codebase.
I'm not sure if something like VisualSVN can handle this, but there must be a product out there.
Virtually every source control will satisfy the #2 and #3 requirement with branches.
For #1 it's more tricky. If you really want a Seamless integration (capital S) then Team Foundation Server is your only choice. (It's very expensive)
Otherwise virtually all the major source control systems will have some sort of VS plugin, but the plugin usually doesn't work very well.
The two most popular free source control systems are:
Subversion
git
The best way to create different additions of your software using the same code in all of the different versions it to use pre-processor directives to conditionally compile your software based of flags that you set.
For information on conditional compilation please see the following links:
.NET: http://msdn.microsoft.com/en-us/library/9ae6e432%28VS.71%29.aspx
Java: http://weblogs.java.net/blog/schaefa/archive/2005/01/how_to_do_condi_1.html
C++: http://www.devarticles.com/c/a/Cplusplus/C-plus-plus-Preprocessor-The-Code-in-the-Middle/3/
I hope this answers your question I use this alot when developing different version of applications for different platforms.
An example of this is an application that I developed in c# for both a server and mobile device implementation. Each had different ways of calling functions in .NET libraries but the logic was the same so I used preprocessor conditional compilation to compile to correct code for each platform but leave the logic intact.
From experience you only need integration with Visual Studio if you need to check out the file before editing it (a-la SourceSafe) and the file is read-only until then.
Having used SourceSafe I went on to using SVN and absolutely never looked back. Then I switched to git and again never looked back on SVN or Sourcesafe.
I can't comment on Team Foundation source control or Mercurial, I've never used those. At this stage I would recommend git over SVN as it's more suited to working with a single source tree that has minor changes between lots of branches. You can do the same thing with SVN but found the process of switching the working copy to another process painful.
Team Foundation Server provides the best seamless integration to VS 2008, but of course its not free (i agree that its very expensive)
have you tried using AnkhSVN? its got a pretty good integration for VS 2008 and SVN. so far it gives me the VS-SVN integration that I need, so you might want to check it and see if it fits your needs.
you can use TortoiseSVN, but I suggest installing CollabNet's SVN server, because AnkhSVN integrates seamlessly with it, plus you dont have to worry about major installations
It's only three months until VS 2010 is in final release (March 22, 2010). For MSDN subscribers, TFS will be integrated into Visual Studio (all levels except Express). MSDN subscriptions that include Visual Studio (any level) will include TFS with a one-seat license. TFS 2010 will run on Vista or Windows 7. SharePoint is no longer required, but you still need it if you want 100% of TFS features, like reporting.
It's all available now in beta; I'm running TFS on my laptop.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
My company is building a product. It's going to be versioned by SVN. It's a webapp so basically there will never be a version out which doesn't have some features in them and thus could always be labeled as beta. But since it's going to be a corporate product I really don't want the "unstable watchout" on there. So how would you go about versioning? Is 1.0 stable? Should the build date be in the version number? Tell me what you guys think!
[major].[minor].[release].[build]
major: Really a marketing decision. Are you ready to call the version 1.0? Does the company consider this a major version for which customers might have to pay more, or is it an update of the current major version which may be free? Less of an R&D decision and more a product decision.
minor: Starts from 0 whenever major is incremented. +1 for every version that goes public.
release: Every time you hit a development milestone and release the product, even internally (e.g. to QA), increment this. This is especially important for communication between teams in the organization. Needless to say, never release the same 'release' twice (even internally). Reset to 0 upon minor++ or major++.
build: Can be a SVN revision, I find that works best.
Examples
My current chrome: 83.0.4103.61
x.y.z.g
increments in g are unstable. (or RCs)
increments in z are stable and mean bug fixes.
increments in y are stable and mean new features.
increments in x are stable, major release without 100% backward compatibility.
I once wrote an elaborate "versioning style guide" for a large project of mine. The project failed to materialize, but the style guide is still available online. It's my personal opinion, perhaps it is helpful (or inspirational) to you.
Beware, it's a long text, and goes into component versioning vs. product versioning and stuff like that. It also expresses strong opinions on some versioning schemes popular in the OSS community, but I have them, so I express them. ;-)
I disagree with using the Subversion revision number, for example. You might want to maintain a released version while continuing development in TRUNK, so you'll set up a maintenance branch - and your revision number versioning goes down the drain.
Edit: As a summary, it distinguishes between versioning source files, components, and the overall product. It uses a system of seperate x.y versoning for components and the product, with a nice interdependency between the two that makes tracing which component version belongs to which product version trivial. It also talks about how to handle alpha / beta / release / patch cycles without breaking the system. Actually, it's a modus operandi for the whole development cycle, so you might want to cherry-pick. ;-)
Edit 2: As enough people found my article useful to make this a "Nice Answer", I started working on the article again. PDF and LaTeX versions are now available, a complete rewrite including better language and explanatory graphics will follow as soon as I can find the time. Thank you for your votes!
Get yourself some inspiration from Wikipedia: "Software versioning"
Another "new" and "relatively popular" option is Semantic Versioning
Summary:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
a.b.c.d
Increments : when
- d: bug fixes
- c: maintenance, e.g. performance improvement
- b: new features
- a: architecture change
The mandatory is the most left one e.g. if there are for example a new feature and a bug fixed then you only have to increment b.
Based on my experience with complex enterprise platform level dependency management and release versioning I've come to recommend an approach I like to call Semi-Semantic Versioning.
Basically it builds off of Semantic Versioning 2.0 but is not quite as strict.
Semi-Semantic Version Segments:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Primary Release Segment Format:
MARKETTING.MAJOR.MINOR.PATCH
Each segment should allow alphanumerics, but pure numerics are recommended for logical incremental changes.
Like SemVer, I recommend Major, Minor, and Patch components to represent reverse compatibility tiers, but I also recommend prepending a Marketing component. This allows product owners, feature epics/groups, and business concerns to bump the primary component independent of technical compatibility concerns.
Unlike other answers, I don't recommended appending a Build number to the primary segment. Instead, add a Post-Release Segment following a '+' (ex: 1.1.0.0+build.42). SemVer calls this build metadata, but I think Post-Release Segment is clearer. This segment is great for declaring the suffix data as not related to the compatibility info in the primary Release Segment. Your continuous integration builds can then be given the previous release number appended with an incremental build number that resets after each primary release (ex: 1.1.0.0 -> 1.1.0.0+build.1 -> 1.1.0.0+build.2 -> 1.1.0.1 ). Some people alternately like to put the svn revision number here or the git commit sha to make it easy to tie to the code repository. Another option is to use the post-release segment for hotfixes and patches, tho it might be worth considering adding a new primary release component for that. It can always get dropped when the patch component is incremented, since the versions are effectively left-aligned and sorted.
In addition to the release and post-release segments, people often want to use a Pre-Release Segment to indicate almost-stable pre-releases like alphas, betas and release candidates. The SemVer approach to this works well, but I recommend separating numerical components from alpha-numeric classifiers (ex: 1.2.0.0+alpha.2 or 1.2.0.0+RC.2). Normally you would bump the release segment at the same time as adding the post-release segment and then drop the pre-release segment when you next bump them primary release segment (ex: 1.0.1.2 -> 1.2.0.0-RC.1 -> 1.2.0.0). Pre-release segments get added to indicate that the release version is coming up, usually just a fixed set of features for more in-depth testing and sharing that doesn't change minute to minute based on more commits.
The beauty of having all of this semantically defined in a way that covers almost all use-cases is that you can parse, sort, compare and increment them in a standard way. This is especially important when using CI systems for complex applications with lots of small independently versioned components (like micro-services) each with their own managed dependencies.
If you're interested, I wrote a semi-semantic parser in ruby. I needed to not just use this pattern but be able to manage other apps that used it.
"Version numbers" are a matter for your internal version control system. Release numbers are a different matter (and should be KEPT different).
Stick to a simple MAJOR.MINOR release system (like v1.27), where MAJOR is the compatibility level (version 2.x is incompatible with or at least majorly different from version 1.x) and MINOR is your bugfix releases or minor enhancements. As long as you follow the X.Y format, you can also use other systems like YEAR.MONTH (2009.12) or YEAR.RELEASE (2009.3). But really you're probably best sticking to MAJOR.MINOR unless you have a good reason not to.
Definitely don't use anything that doesn't fit the X.Y format, as it'll make it tough for distros, announcement websites, etc. to work with you, and that alone could seriously affect your project's popularity.
Use branches and tags in your (preferably distributed) version control system to mark specific internal version numbers as relating to MAJORS and MINORS respectively.
And yes, 1.0 should be stable. All releases should be stable, unless they're marked alpha, beta, or RC. Use Alphas for known-broken-and-incomplete. Betas for known-broken. RCs for "try it; you'll probably spot things we missed". Anything without one of these should (ideally, of course) be tested, known good, have an up to date manual, etc.
Version scheme: [major].[minor].[devrel][mark]
[major]: increment if you have a drastic change in development.
[minor]: increment if you have a minor change in development.
[devrel]: increment if you have a bug fix. Reset to zero if major++ or minor++.
[mark]: a, b or rc: a is an alpha release, b is beta release, and rc is a release candidate. Note that versions like 1.3.57a or 1.3.57b or 1.3.57rc is before the version 1.3.57. Start at 0.0.0.
It's pretty popular these days to just use the Subversion revision number.
If it's in SVN then why not use the SVN revision number?
If you look at the bottom right of this web page you'll see the Stack Overflow version number which is the SVN revision number.
Versioning is up to you; I'd put 1.0 on the first version I was confident in. You may want to follow it up quickly with other versions, since some software vendors have given 1.0 a bad reputation.
You do want some way of tying the version number to the exact build used, but you probably want it to be nice and simple for your end users. Consider using standard version numbers, and tagging the SVN repository with the version number included.
While just going with the Subversion revision number is nice and simple, it does remove information from the version number. Users might consider this a bad thing.
I assume that your webapp will have some kind of deployment procedure, so that not each revision in Subversion is actually published. Since it is impossible from the "outside" (from the user's perspective) to determine when releases are being made, and how many revisions the code will undergo between them, it makes the numbers almost random. They will be increasing, and I guess it's possible to surmise some kind of distance from comparing two revisions, but not much.
Classical version numbers tend to "dramatize" releases, so that users can build some kind of expectation. It is easier to think "I have version 1.0, now version 1.1 is out adding this and that, that sounds interesting" than to think "yesterday we ran SO revision 2587, today it's 3233, it must be lots better!".
Of course, this dramatization can be inflated too, with companies picking version numbers that are meant to sound more interesting than is motivated by the actual differences in the product, I guess going with the revision number counters this a bit.
We've spent way too much time deciding when to increment the major version. Some shops would rarely do it so you would have releases like 1.25.3 and others would do it for ever release giving you 15.0
I got fed up with that and convinced everyone the major release number is just the year and the minor is just a sequential release within the year. The users seemed to like it and it's a no-brainer to come-up with the next version number.
Year.Release.build
year = current year
release = sequence # of public releases with
new functionality - reset to 1 every
year
build = incremented for bug
fixes and internal releases
EDIT
** Now this was for an internal app that was continually enhanced **
This would probably not work for commercial apps where it's important to have major releases at different times of the year for marketing and financial purposes.
The reason why this question exists is because we don't have a single agreed upon way to do configuration management.
The way I like to do version number is just increment integer from 1. I don't want a multi part version number that I will have to explain or document. And I don't want to use SVN rev number as that will require some explaining as well.
You would need some release scripts on top of SVN to make this happen
I have very little experience in the area. However, here's what I'd do:
Choose a scheme for numbering revisions and stick to it. Be consistent.
Each version change should represent a significant change. How small a change is significant and the levels of change that are reflected in the version number are up to you.
Of course, you can just use the svn revision number --- like many others have suggested!!!
I hope this helps.
We use a simple major.minor.julian_date syntax.
Where;
major - First release is 1 and then when we introduce major new features or changes so significant they are not backwards compatible increase this number.
minor - The major milestone releases. For each build pushed by production this number increases.
julian_date - The Julian Day the build was pushed to QA.
Example of the first release pushed to QA on 1/15 is -> 1.0.015
Example of the first release pushed to Production on 3/4 is -> 1.1.063
It's not perfect, but handy as we push builds to QA near daily.
Some good info here:
When to Change File/Assembly Versions
First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.
Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.
But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.
Shipping Builds
As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.
When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.
Or to use your 'thought' version number comma subversion number..
z.B.:
1.0.101 // revision 101, release
or 1.0.101-090303 // with release date, i use this