In the last few weeks, my job is to make my mates job easier. I have been installing a simple Continuous Integration System, Maven plugins and Eclipse add-ons.
I can't share a lot of this information until I have learned it properly. I would want to show that with good examples and error-solving snippets.
What I can tell you right now is the versioning system of apache, I liked it too much because it is simply, easy to learn and use, easy to learn, teach, memorize..
http://apr.apache.org/versioning.html
This system is used by lots of other software companies, let's explain in few words:
Let's take a random version: 3.2.1, for example.
You resolve a bug, and make a patch for your clients, increment the third number.
You create a feature, but you don't change any of previously existent functionality, increment the second number.
You change a functionality, breaking the contract of your previous versions. increment the first number.
The result might be the following.
Previous version: 3.2.1
You upgrade to 3.2.2
It is supposed to be fully compatible
Previous version: 3.2.1
You downgrade to 3.2.0
It is supposed to be fully compatible. Obviously, it could work worse, there is an absent patch.
Previous version: 3.2.1
You upgrade to 3.3.1 (or 3.3.0)
It is supposed to be fully compatible with the same configuration.
Previous version: 3.2.1
You downgrade to 3.1.1 (or 3.1.x)
Compatibility with prior minor versions is not guaranteed. *
Previous version: 3.2.1
You upgrade to 4.2.1 (or 4.x.x)
Compatibility with different major versions is not guaranteed.
Previous version: 3.2.1
You downgrade to 2.2.1 (or 2.x.x)
Compatibility with different major versions is not guaranteed. *
* The best explanation for this phenomenon is, lets say, 3.2.1 introduced two lines in configuration files, which are parsed with a certain pattern. It could be possible that previous version was not able to parse your configuration with those unknown new lines.
A good coherent versioning system will give free information to your team and customers about how compatible your versions are between them. Avoid marketing formulas for your version, at least, inside your I.T. department. You could also use standard tools for autoincrement versions, like Maven (sooooon).
See you at @anavarro_prof twitter ;)
This blog is written for teaching about Java technologies and best-practices. I will talk about patterns, Maven, J2EE, Artifactory, Hudson, Sonar, and so on.
Suscribirse a:
Enviar comentarios (Atom)
Etiquetas
maven
logstash
vrr
logback
json
matrix
artifactory
cis
configuration
CheckStyle
developers
devops
filebeat
ops
elasticsearch
importance
installation
java
priority
severity
tomcat
SpringSource
book of the month
critical
debug
important
log
low
plugin
What if
code repository
curator
dependencies
essential readings
essentials
structured arguments
Eclipse
Formatter
Tunning
apache
basic
best practices
codegen
continuous deployment
continuous integration
contract-first
deploy
gradle
jenkins
kibana
lombok
manager
nexus
opinion
performance
persistence
pom.xml
slf4j
storage
svn
testing
401
409
ChekStyle
Error
Homogeneous
JavaMelody
Managing
Monitoring
Scrum
Solution
Style
Trenches
XP
advantages
algorithm
ansible
architecture
aws
bitbucket
cabotrafalgar
cd
chargers
cheap
chef
ci
comparison
cons
cow
cvs
dependences
disk
distribution
docker
docker-compose
documentation
eb
ecs
elastic
elk
ender's game
enforcing
essential tools
estimation
external
fail
findbugs
folders
git
github
grok
html
hudson
ide
inheritance
javadoc
jcl
jmr
jmx
kv
libvirt
lifecycle
load
log4j
logbacl
logger
low cost
mdc
memory
multiple files
mysql
nature
nifty-gui nifty-flow
organization
permissions
pmd
pragmatic programmer
profiles
pros
puppet
q outside the office
release
remote
reporting
save
security
several files
simulated annealing
site
snapshot
sonar
standard
strategies
stress
suppressions
surveillance
tale
throughput
unit
upload
usvn
vagrant
versioning
war
wires
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.