I just found Visual Studio Code (http://code.visualstudio.com) and wanted to give it a try. But when I read the license terms (yes - I really did) I saw the following point:
TIME-SENSITIVE SOFTWARE. The software will stop running on 31/12/2016 (day/month/year). You will not receive any other notice. You may not be able to access data used with the software when it stops running.
This seems a bit strange. What happens after the end of the year - in the worst case I will not be able to use it any more, or maybe it will not be free any more but I need to pay? There might be other reasons for this term - does anyone know?
This is a great question. I am a Program Manager on the Visual Studio Code team and happy to try to answer it.
Typically our pre-release software has an expiration defined in the license to encourage moving to officially released versions of products when they become available. Released products generally have different license terms, support policies, data collection policies, etc.
Visual Studio Code follows this model. It is currently in "Beta" and has a 31 Dec 2016 termination date in its license. We chose that date because we felt it was well outside the timeframe in which we would delare general availablity ("GA" or "1.0") and become an officially released product. The in product expiration helps with compliance because the product will not run after the license expires.
When we declare GA we will make two significant changes to the license. First, we are removing the termination date from the license and from the product. Second, we will allow users opt-out of data collection. VS Code will continue to be free and Insiders builds will always be Beta.
Thanks again for asking the question, I hope this explanation makes it more clear. I'll post a link to this in our wiki.
The internal application which my team works on is currently on a version 10.y.z.build_number.
During a discussion if the next release is significant enough for 10.y+1.z.build_number or it should be 10.y.z+1.build_number I suggested that we could keep it simple and align the version numbers with the calendar.
For example the next release would be 13.8.1.build_number which stands for the 1st release for August 2013. The September one would be 13.9.1.build_number.
The idea has been discarded for now.
For a paid application I can imagine that having the 1st number is useful to easily distinguish between releases with free upgrades and major releases which require paid update. x+1.y.z would be paid and x.y+1.z would be free.
After a quick search I found Jeff Attwood's What's In a Version Number, Anyway?.
However for an unpaid internal application I cannot think of weak points for the calendar-aligned version numbers and the beauty of simplicity speaks to me. As one of the comments on Jeff Atwood's post says: Microsoft Office 2003 is a far more meaningful name than Microsoft Office 11.
The question:
Is my vision clouded by enthusiasm and are there known issues for calendar-aligned version numbers?
For an internal application, the information that the version needs to convey is the revision or commit of the sources from which said app is built.
Since you have access to the VCS managing that app sources, the version can help bug reporting like: "found in revision xxx".
That is far more valuable that a date-based tag, which can be subject to interpretation in order to find the exact version of the sources exhibiting a bug that need to be reporting.
You can combine that with any version policy you want, with tags: git, for instance, can generate a unique version number based on SHA1 + a tag. See:
"Deriving application build version from git describe - how to get a relatively straightforward string?"
"Simulating a global revision number with git"
But the idea remains: date is a metadata managed by a VCS or a build scheduler like Jenkins/Hudson/TeamCity... It doesn't have to be in the public version number of the app.
What need to be in that version number is an info allowing to get the exact sources from which that app was built.
I am looking for a solution to license a WPF, Silverlight and WP7 assembly. The assembly in question is a chart control which has a single API for use across platforms. I am in the process of creating a separate MSI for each platform (WPF, SL, WP7) which users will be able to download and install. This will register the assemblies in their GAC for development use.
What I would like to do is ensure that a single development license is only used by a single developer. It doesn't have to be super secure, just enough to deter would-be hackers. Ideally a solution that covered all three platforms would be beneficial.
I already have a cross-platform obfuscator which I am very pleased with. Shame this doesn't include licensing!
Edit: Additional requirements are that I will be allowing users to download updates for up to one year from purchase date, however the assemblies they purchase will be available for their use indefinitely whether or not they update. Assemblies are to be redistributed so any licensing model must be redistributable on WPF/SL/WP7 platforms.
Your suggestions / comments welcome.
Best regards,
For your requirements that the licencing methodology 'will "do the job" and prevent low-level licence abuse' I would personally recommend not getting too fancy; that is, to avoid the use of web-activated/maintained licencing. My advice would be similar to the approach outlined here.
Select a symmetric encryption algorithm using the one of the .NET libraries as described in the link above.
Create the required encryption key using a random generator (if you contact me I am happy to share a piece of code I developed to generate a variety of random strings/keys for any required key size), there are also .NET classes to help you do this yourself by generating pseudo-random numbers (RNGCryptoServiceProvider).
Transform/’custom-hash’ the key to provide a new 'hashed encryption key'.
Use this key to generate an Initialisation Vector (IV) and encrypt your licence file.
How you now deploy the application (in terms of licencing) is up to you. The two methods below will work for all three application types above and will offer some degree of consistency for the licencing of each of your products. The above method uses two files for licencing. 'ProductKey.myExtension' and 'LicenceFile.myOtherExtension'. The first contains the randomly generated key, that will be 'hashed'/transformed in the same way as in the licence generator application (you will need a separate (small) application to ‘cut’/create the licence files). The second is the encrypted file with user info, licence period etc.
A. You could now provide an install package for your application that will install your application in the relevant directory (i.e. C:\Pogram Files etc.) without providing the licence files, in which case you can deploy the licence files with a licence installer. The licence could then separately be installed for each user employing `Environment.SpecialFolder's to ensure each user has their own licence (of course this would assume that the 'Administrator' installed the application in the first instance for all users and that the licence install pack would be run on a user-by-user basis). Note: I am currently not familiar with WP7 applications and the specifics in this case.
B. The second way would be to allow individual users to install the application, and to install the relevant licence files upon the applications installation.
I have deployed several WinForm applications using this methodology after an extensive research period and it seems to work well. I hope this is of some help.
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.