So I've only recently started to dive head first into web development. One thing I gathered very quickly was that ES5 = old, and ES6 = shiny and new. I figured ES6 was the latest and greatest ES had to offer. But I just found out that ES6 is 3 standards behind, and that some of the features I've been using and loving aren't even a part of it—they came in later specifications. So why does everything I read make it seem like there's just ES5 and ES6?
ES6 (later rebranded as ES2015) simply was the first release after the language design process was ramped up. After vendors agreed to improve JavaScript and implement new features in their engines (which were possible before only using transpilers like CoffeeScript), lots of feature proposals were made and discussed under the term ES-harmony, with ES6 - the next revision of the standard that was expected to contain all those new features - being the big buzzword.
When ES6 finally came, it was a major release that included a plethora of new features, but not all of the previously discussed ones. The standards committee kept up their work, and changed to a new yearly release cycle (ES7=ES2016, ES8=ES2017, ES9=ES2018, …). Lots of fancy things were expected to be included in ES7 (the new buzzword, along with ES6+), but ultimately failed to be finished on time (see Is ES7 only composed of two features?). The TC39 committee then codified a process for adopting proposals which is still followed, and things get included in the specification releases (referred to as ES-next) when they're done. The importance of the standard revisions declined, features are denoted by the name of the proposal and not by the year they are expected to get released.
Related
I recently contributed some code to an open source library/tool just before I realized that I'd like to re-write this project myself (different programming language and design choices). However, some aspects of the project are just like I would have done them myself or are simply worth "copying". Even if I tried really hard to forget about the original code -- most class names, constants and other stuff just are naturally named the same. The original project's license is AGPL.
Can I use a different license (e.g. MIT)? Which ones?
Will I have to mention the original project somewhere?
If so, where? And will I ever be allowed to remove the notice (maybe after the two projects have truly diverged after a few years of development)?
I am not a lawyer and this is probably not the correct venue for soliciting legal advice.
However, this is my take, as one FOSS contributor to another.
Generally speaking when you contribute to open source projects, you retain the copyright over the code that you wrote, and you release it under a license that permits everyone to use modify and distribute it.
Thus, you retain the right to relicense code that you so contributed under MIT or another license. That doesn't count as "stealing" the code and erasing the GPL license -- you were the original source and you retain the right to release what was originally yours again under a different license.
In some projects, the leaders may request that people DO transfer copyright, although its pretty rare I think. You should check the licensing statement to be sure. Unless there is something in writing somewhere saying that you explicitly agree to transfer copyright to them, then most likely you retained it.
You do not have the right to relicense other peoples work though. In cases where you modified someone elses code, contributing some changes to their class or something, you probably become joint owners, and at least I would not feel comfortable copying the part that they made and relicensing it without permission.
That's just the text of the code though. If you want to rewrite another program from scratch, using a similar high level plan but different execution, I don't think copyright will encumber you. Intellectual property law can still encumber you if some technique or method in the code is covered by a software patent. But it doesn't sound like that's the case here.
To avoid legal issues, sometimes companies / groups of people will use "clean room design" (https://en.wikipedia.org/wiki/Clean_room_design). But iiuc this is just done as a precaution to unambiguously head off any possible lawsuit -- the law does not require that you use such techniques just because you once looked at GPL code, iiuc.
For an example of this playing out, you can look at the history of the MinGW cross compiler project, and the mingw-w64 spin-off of it, which originally began because a private company wanted a version of mingw which supported 64-bit processors and other things, and so used clean room design to reverse engineer the project. The result of this was eventually made fully open source, but was not accepted back into the original mingw project and so there are now two projects. (Hope that this is a fair and impartial summary of the history.)
https://en.wikipedia.org/wiki/MinGW#History
Title says it all. What, if any, Is the difference between a software 'release' and a 'version'?
Do these two definitions overlap? Is it the case that all releases, and release candidates are versions, but not all versions are releases?
Here's a simplistic explanation:
Build − executable or a library created by compiling source code.
Version − a software build. New version is a different build.
Release − (public release) a version intended for use by general population.
Build #465832567 is just the number of times the main developer compiled the program (or library). Sensible developers only release builds with meaningful and tested changes.
Version 2.1.5 means it's the second edition with at least 1 major difference from its 2.0.~ predecessors and 5 minor feature updates or bug fixes.
"Public release" usually means it's a version for normal users who are not involved in testing or development of the software.
Different release types example:
Firefox − browser version for simple users
Aurora − so called "alpha" version, which includes latest additions, some untested
Nightly − "beta" version for developers and enthusiasts who don't fear bugs and crashes
I am not sure if there is a very concrete on these two terms, and the definition seems also differs base on context.
Normally Release is more about the "action" to distribute the software to interested candidates, while "version" is an identifier of certain snapshot of the software (mostly a meaningful snapshot).
Therefore, in most case, as we need to identify certain release of the application, we will have a version assigned. (There are always exceptions anyway...)
Definition of version:
a particular form of something differing in certain respects from an earlier form or other forms of the same type of thing.
Think of it this way.
When you edit the code, depending apon what you consider a change (saving, publishing, or just editing), your code version changes (depending on how large of a difference you consider a version- also note that versioning systems can be whatever you decide). You might have a version of code where there is a bug, then you patch it, and you have another version. What you call your versions can be whatever you want (versioning system).
A release is commonly considered a version that is pretty stable, complete, tested and most likely having few known bugs and then made public, although more technically its ANY version made public. However, when you see the word release I feel it is safe to assume it is the first provided you cant figure it out by context.
This is my second post so I hope it was helpful!
A release describes more the process of publishing a software than a concrete material thing. Whereas a version is a concrete and specific software package. Because you won’t publish all software versions you build, only the software versions that you publish or deliver are called software releases. A build is the process of compiling and packaging of a software. Because you can build one and the same code more than once at different machines and with different compilers in different environments a build is the outcome of compile and packaging code and software parts.
Imagine you plan, design, develop, build and test a software. All this steps bring you towards a software release. Because you don’t exactly know how much fixes and versions your team has to build and your quality assurance rejects you must define an objective for you team and your customers. So a release is an objective your team develops towards.
So let’s say you plan your first release in November. The objective of your team is to create a “Halloween Release”. Towards this “Halloween Release” you think it’s clever to present it to our QA before delivering the first version to key users or customers. So the intermediate objective of your team is to create a QA-Release or Alpha-Release. After the 1001st build you present a first running version for example 1.0-alpha-build-1001 to your QA. But your QA rejects this version and the following version as well. So you further fix, improve and build to get a Beta Release that your QA accepts for presentation to key users. Then some builds after, your QA confirms so you can present 1.0-beta-build-4711 to your key users; your first Beta-Release. After some improvements you publish your “Halloween Release” at November with version 1.0 as final software version to your customers. But unfortunately some customers complain about minor issues and some users do complain about missing features. In consequence you decide to fix the issues on the one hand and to integrate new features on the other hand. So your team has two goals and objectives, first to fix and to work towards a “Bugfix release” and second to work for a “Christmas Release” with the new features.
So you fix and build a “Bugfix release”, maybe resulting in a version 1.1. In parallel your team creates new features, integrates, tests and builds a “Christmas release”, resulting in a version 2.0 you deliver at Christmas to your customers.
So in one sentence: A release is a challenge towards a version, you deliver to a particular addresse:
QA-Releases for your QA to examine your software.
Beta-Releases for your key users to introduce new features.
Customer releases for customers to satisfy customers and make money.
Seasonal releases and other releases for funny as serious objectives as well.
Very soon we are going to start on open-source (py+qt) project which is supposed to be multi-platform (we're using FreeBSD as native platform) and we're not sure which DVCS/hosting to use.
In the past we were using darcs for very long time, but moved away from it due to not having adequate public hosting available. Played for some time with Monotone - nicely designed, but mostly niche today. Fossil is nice, but it uses non-standard wiki and its tracker is functional, but we expect more.
Considering that we won't work on kernel-like sized project we do not nee Git which we consider too complex to deal with it, especially for potential contributors which might use Windows OS and prefer GUI tools.
So, the story comes to Bazaar/Launchpad and Mercurial/Bitbucket...
Here are some pro/cons which we gathered together, but would like to hear if we missed something which might help us to decide...
Bazaar pro/cons:
2.4 is probably quick enough for our needs ,
simple to use,
has nice GUI tool (explorer),
handles empty directories,
(probably) less popular than Mercurial,
does not have equivalent of hg's named branches
The last point is probably not to important 'cause there are nicks and there is colo-branches plugin, so one can get same/similar functionality.
The most problematic quirk we find in Bazaar it its revision numbers scheme and problem which can arise if one pushes from feature branch into upstream which would change revids.
Maybe it's a lesser problem when using Launchpad...
As far s Launchpad is concerned:
- it has very nice bug tracker with email interface
- it's (maybe) more project-oriented than Bitbucket
- no private repos as with Bitbucket
- no wiki for projects - bug (https://bugs.launchpad.net/launchpad/+bug/240067) is more than 3 years old and still with 'Low priority'. LP is the only one amongst {LP,Sourceforge,Bitbucket, Google, Github} which lacks this feature and it really sucks and degrades, otherwise, nice hosting solution.
What we've found in The other camp...
Mercurial is:
(probably) more popular than Bazaar,
quick,
simple to use,
there is nice TortoiseHG for non cli-savvy users,
we like named branches,
some quirks like handling empty directories (or https://www.mercurial-scm.org/bts/issue29)
However, what we like the most over Bazaar is, as we believe, great merging capabilities without the hassle of changed revids due to revno:hash schema.
As far as Bitbucket:
we like to have unlimited/private repos
we like having wikis available for the project(s)
we miss email interface for the tracker and the tracker is (maybe) not on par with the one at LP (reviews etc.)
At the end, let's say that there are some projects which we are interested in which are under Git #github, so we would like to use single DVCS which can helps us inter-operate with git#github projects.
We find that bzr-git plugin is very capable and do not have experience with hg-git.
Although there is bzr-hg plugin (not as mature as bzr-git), but we do not know about something like hg-bzr except hg's convert extension which does the job of hg-bzr conversion.
Is there any important feature which we did miss having important consequence in deciding about the two?
Finally, we use DVCS for all our needs (simple project, writings...) and we'd prefer to settle on one DVCS/hosting which can serve all our purposes and be useful in contributing to git(hub) projects as well.
What do you recommend?
In Bazaar:
You can avoid the problem of revision numbers being renumbered by setting append_revisions_only in branch.conf, which will make sure people only merge into trunk, rather than switching the trunk around.
I like bzr-colo a lot for dealing with named colocated branches.
I would certainly like to see Launchpad get wikis. It's assigned and in progress at the moment so perhaps it will get done soon.
Update: Seing this comment makes it easier for us to abandon bzr/LP and embrace hg/bitbucket.
Imagine you have a program written e.g. in Java 1.4 or C# 1.0. Of course this program doesn't use generics and other language features that were introduced with later versions.
Now some non-trivial changes have to be made. And of course, you already have a newer IDE/compiler so you could use Java 1.6 resp. C# 3.5 instead. Would you use this oppurtunity to upgrade to the latest language features, i.e. use generic containers and get rid of many casts, etc. Or would you leave it like it is, and use the new features only for new parts. Or even stay with the features of the version originaly used, to maintain a level of consistency?
My basic rule for code maintenance: If it ain't broke, don't fix it.
It's just one specific form of refactoring, so all the advice on when and how to do that applies.
One consideration here is your present and future ability to attract and retain developers to perform maintenance and support on an application built with outdated technology. Many seasoned developers worked with those older versions of Java and C# when they were current, so it isn't that we have no experience with it. But if we spend, say, a year working in .Net 1.0, we will be forgetting what we now know about subsequent versions. And while we are spending that year working in old technology, all of our friends and competitors are honing their skills on the latest technology. We will never be able to make that year up.
In addition to falling behind, we will find it intensely frustrating not to be able to use the functionality in the later versions that we are now comfortable using.
So, younger developers will not have had experience in older technology (.Net 1.0 was released in January 2002). Older developers have been there and don't want to go back.
On the other hand, if you stay back in the older version, you will be comfortable with your skillset. You won't have to spend a lot of time learning about newer technologies. And perhaps best of all, you will have job security.
As far as possible, leave working code alone. It may seem like the code should all be using the latest programming secret sauce, but there is a lot to be said for tried and tested code.
I would only consider rewriting code that must be heavily modified in any case to add a new feature, and even then I would only change the programming metaphor if it will speed up the writing of the new feature.
Otherwise you will constantly be debugging code which was previously working, and using up energy that could have gone into improving the product.
It depends. Does it need to be compiled by old compilers? Do you have enough time/money to change everything?
In theory, it's a simple balance between costs and benefits, so you should only do the rewrite if the benefits outweigh the costs.
The problem with that is that it's almost impossible to measure the real costs (not only of doing the work, but of not doing other things that might contribute more). Generally speaking, the benefits can't really be measured at all -- you can only guess at how much difficult something would be if you'd stayed with the old code.
That leaves us with little chance to do anything based on rational measurements. That leaves a simple rule of thumb: leave old code alone until your only choices are to rewrite it or abandon it completely.
Context: I work at a small software company that has traditionally done research-type work, and does not have much experience in the commercial space. We are now trying to push into the commercial world. Due to our origins in research we are used to a very rapid development cycle and very little structure in terms of maintaining proper versions of projects.
Problem: The lack of structure is now proving to be somewhat of a hindrance, as every developer has a slightly different view of the code base. A problem one developer discovers is not reproducible by another developer, and problems found in one build may disappear in the next (or worse, new problems may appear). This makes for a very frustrating experience for someone who is responsible for integrating all the projects and ensuring quality and performance standards are met - i.e. myself.
Potential solution: Personally I am convinced we need to enforce better structure via fixed version numbers and regular releases. It should be self-evident how proper versioning would help with many of our problems, but of course it is not without problems - developers need to do extra work to perform and test releases, and will no longer be able to use the latest versions of everything.
Question: To come to a point - what sorts of strategies do you recommend for ensuring the process and effort required for releases occurs as smoothly as possible? We are using git for version control, maven for our build system, and we have bug tracking and continuous integration systems running, so I believe the tools are there. I am simply unsure about what a proper release process should look like.
You have the big three in place: version control, one-click build via Maven and your continuous build server, and bug tracking. It sounds like you guys are gravitating towards Agile methodologies, and so you ought to be trying to keep the trunk version of your product in a near deliverable state at all times.
When you decide to make your first release, create a branch off of your trunk version for that release. Decide on a labelling scheme and be sure to label the branch version. For example, your first release could be 1.0.4530, where the 1 means first version, the 0 means it's the first release candidate, and the 4530 is the version control change number. You test this release branch and fix important bugs on it. After a while you issue another release candidate, say 1.1.4807. This process iterates a couple more times (say), your release becomes good enough, and you ship version 1.3.5167.
Meanwhile, your new development occurs only in the trunk version, and from time to time you'll need to merge bug fixes from the 1.x release branch back to the trunk. Later, you'll split off a 2.x branch from the trunk to repeat the process for your second release. You'll generally have several active branches (plus the trunk), with development limited to the trunk and each branch kept pristine and independent from development.
You guys will get the hang of things and your developer coordination problems will become less frequent. But these problems are nearly all going to be limited to the trunk, not the release branches.
A problem one developer discovers is
not reproducible by another developer,
and problems found in one build may
disappear in the next (or worse, new
problems may appear). This makes for a
very frustrating experience for
someone who is responsible for
integrating all the projects and
ensuring quality and performance
standards are met - i.e. myself.
Potential solution: Personally I am
convinced we need to enforce better
structure via fixed version numbers
and regular releases.
I don't think you need to have very frequent releases just to coordinate internally. You can do that through version control. Just have people talk about specific git revisions when reporting issues. Also note that you will have to coordinate any external dependencies/libraries too. Some kind of vendor branches could help with this.
It sound like the developers need to use "test branches" and respect the "stable/production branch" a little bit more.
Sell in the concept of "do your wild west stuff in this branch", and when you are happy with the results then you merge it into this "boring stable production branch"....
(or something like that)
There are books written about the general topic; Amazon search even returns three titles for specialized "version control with git."
I think you will benefit from defining a canonical view of the code base. Call it Test. A problem is a problem if it appears in Test. If a problem does not appear in some developer's view, it is up to that developer to figure out what is the important difference; and likewise for a problem that appears in a developer's view, but not in Test.
One convention is for Test to be re-built from sources on a nightly basis. A more strenuous convention is for Test to be re-built upon every update. If your team is small (five or fewer) and not dispersed over great distances or multiple timezones, a reasonable first approximation is to make Test a git workspace on a server upon which your toolchain has been installed along with some cron jobs so that this workspace is updated and rebuilt every night (usually).