Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour,
un numéro de version se divise en 4 parties ( de gauche à droite)
major
minor
build
revision
la règle ( en général ) est la suivante :
- on ne change le major et/ou minor que dans le cas où la nouvelle version
est incompatible avec la précédente
- on change le build lors de modifications compatibles avec la version
précédente mais apportant des fonctionnalités nouvelles
- on change le revision lors d'une recompilation après des modifications peu
importantes ( amélioration d'interfaces ou correction de bugs mineurs sur des
fonctionnalités peu utilisées )
On considère que 2 versions sont identiques si le build est le même
C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
En espérant avoir pu vous renseigner
Bonne journée
"Gilles TOURREAU" a écrit :Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour,
un numéro de version se divise en 4 parties ( de gauche à droite)
major
minor
build
revision
la règle ( en général ) est la suivante :
- on ne change le major et/ou minor que dans le cas où la nouvelle version
est incompatible avec la précédente
- on change le build lors de modifications compatibles avec la version
précédente mais apportant des fonctionnalités nouvelles
- on change le revision lors d'une recompilation après des modifications peu
importantes ( amélioration d'interfaces ou correction de bugs mineurs sur des
fonctionnalités peu utilisées )
On considère que 2 versions sont identiques si le build est le même
C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
En espérant avoir pu vous renseigner
Bonne journée
"Gilles TOURREAU" a écrit :
Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour,
un numéro de version se divise en 4 parties ( de gauche à droite)
major
minor
build
revision
la règle ( en général ) est la suivante :
- on ne change le major et/ou minor que dans le cas où la nouvelle version
est incompatible avec la précédente
- on change le build lors de modifications compatibles avec la version
précédente mais apportant des fonctionnalités nouvelles
- on change le revision lors d'une recompilation après des modifications peu
importantes ( amélioration d'interfaces ou correction de bugs mineurs sur des
fonctionnalités peu utilisées )
On considère que 2 versions sont identiques si le build est le même
C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
En espérant avoir pu vous renseigner
Bonne journée
"Gilles TOURREAU" a écrit :Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
papy normand a exprimé avec précision :
> Bonjour,
> un numéro de version se divise en 4 parties ( de gauche à droite)
> major
> minor
> build
> revision
>
> la règle ( en général ) est la suivante :
> - on ne change le major et/ou minor que dans le cas où la nouvelle version
> est incompatible avec la précédente
> - on change le build lors de modifications compatibles avec la version
> précédente mais apportant des fonctionnalités nouvelles
> - on change le revision lors d'une recompilation après des modifications peu
> importantes ( amélioration d'interfaces ou correction de bugs mineurs sur des
> fonctionnalités peu utilisées )
>
> On considère que 2 versions sont identiques si le build est le même
>
> C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
> En espérant avoir pu vous renseigner
> Bonne journée
>
> "Gilles TOURREAU" a écrit :
>
>> Bonjour tout le monde !
>>
>> Une question plus d'organisation que technique :
>>
>> Les numéros de version de .NET sont composées de 4 nombres.
>> Les 2 premiers représentent la version mineur et majeur d'un assembly.
>> Le 4ème, la correction d'un bug.
>>
>> Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
>> l'incrementer ?
>>
>> En vous remerciant par avance de vos lumières...
>>
>> Cordialement
>>
>> --
>> Gilles TOURREAU
>> Responsable informatique
>>
>>
>> Société P.O.S
>> Spécialiste en motoculture depuis + de 30 ans !
>> http://www.pos.fr
>>
>>
>>
Merci pour cette réponse claire, nette et précise !
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
papy normand a exprimé avec précision :
> Bonjour,
> un numéro de version se divise en 4 parties ( de gauche à droite)
> major
> minor
> build
> revision
>
> la règle ( en général ) est la suivante :
> - on ne change le major et/ou minor que dans le cas où la nouvelle version
> est incompatible avec la précédente
> - on change le build lors de modifications compatibles avec la version
> précédente mais apportant des fonctionnalités nouvelles
> - on change le revision lors d'une recompilation après des modifications peu
> importantes ( amélioration d'interfaces ou correction de bugs mineurs sur des
> fonctionnalités peu utilisées )
>
> On considère que 2 versions sont identiques si le build est le même
>
> C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
> En espérant avoir pu vous renseigner
> Bonne journée
>
> "Gilles TOURREAU" a écrit :
>
>> Bonjour tout le monde !
>>
>> Une question plus d'organisation que technique :
>>
>> Les numéros de version de .NET sont composées de 4 nombres.
>> Les 2 premiers représentent la version mineur et majeur d'un assembly.
>> Le 4ème, la correction d'un bug.
>>
>> Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
>> l'incrementer ?
>>
>> En vous remerciant par avance de vos lumières...
>>
>> Cordialement
>>
>> --
>> Gilles TOURREAU
>> Responsable informatique
>> gilles.tourreau@pos.fr
>>
>> Société P.O.S
>> Spécialiste en motoculture depuis + de 30 ans !
>> http://www.pos.fr
>>
>>
>>
Merci pour cette réponse claire, nette et précise !
Cordialement
--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
papy normand a exprimé avec précision :
> Bonjour,
> un numéro de version se divise en 4 parties ( de gauche à droite)
> major
> minor
> build
> revision
>
> la règle ( en général ) est la suivante :
> - on ne change le major et/ou minor que dans le cas où la nouvelle version
> est incompatible avec la précédente
> - on change le build lors de modifications compatibles avec la version
> précédente mais apportant des fonctionnalités nouvelles
> - on change le revision lors d'une recompilation après des modifications peu
> importantes ( amélioration d'interfaces ou correction de bugs mineurs sur des
> fonctionnalités peu utilisées )
>
> On considère que 2 versions sont identiques si le build est le même
>
> C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
> En espérant avoir pu vous renseigner
> Bonne journée
>
> "Gilles TOURREAU" a écrit :
>
>> Bonjour tout le monde !
>>
>> Une question plus d'organisation que technique :
>>
>> Les numéros de version de .NET sont composées de 4 nombres.
>> Les 2 premiers représentent la version mineur et majeur d'un assembly.
>> Le 4ème, la correction d'un bug.
>>
>> Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
>> l'incrementer ?
>>
>> En vous remerciant par avance de vos lumières...
>>
>> Cordialement
>>
>> --
>> Gilles TOURREAU
>> Responsable informatique
>>
>>
>> Société P.O.S
>> Spécialiste en motoculture depuis + de 30 ans !
>> http://www.pos.fr
>>
>>
>>
Merci pour cette réponse claire, nette et précise !
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour,
j'ai retrouvé ceci dans la définition de la propriété Version sur MSDN
adresse : http://msdn2.microsoft.com/en-us/library/system.version.aspx
Version numbers consist of two to four components: major, minor, build, and
revision. The major and minor components are required; the build and revision
components are optional, but the build component is required if the revision
component is defined. All defined components must be integers greater than or
equal to 0. The format of the version number is as follows. Optional
components are shown in square brackets ('[' and ']'):
major.minor[.build[.revision]]
The components are used by convention as follows:
Major : Assemblies with the same name but different major versions are not
interchangeable. This would be appropriate, for example, for a major rewrite
of a product where backward compatibility cannot be assumed.
Minor : If the name and major number on two assemblies are the same, but the
minor number is different, this indicates significant enhancement with the
intention of backward compatibility. This would be appropriate, for example,
on a point release of a product or a fully backward compatible new version of
a product.
Build : A difference in build number represents a recompilation of the same
source. This would be appropriate because of processor, platform, or compiler
changes.
Revision : Assemblies with the same name, major, and minor version numbers
but different revisions are intended to be fully interchangeable. This would
be appropriate to fix a security hole in a previously released assembly.
Subsequent versions of an assembly that differ only by build or revision
numbers are considered to be Hotfix updates of the prior version.
Starting with .NET Framework 2.0, the MajorRevision and MinorRevision
properties enable you to identify a temporary version of your application
that, for example, corrects a problem until you can release a permanent
solution. Furthermore, the Windows NT operating system uses the MajorRevision
property to encode the service pack number.
Ce qui n'est pas forcément très clair.
Pour mes propres dèveloppements, j'applique les règles suivantes :
Major : pour le moment, toujours à 1
Minor : pour le moment, toujours à 1 ( mais correspondrait à d'importantes
modifications dans les fonctionnalités ou à un changement de version du
Framework)
Build : sous la forme aabb
aa correspond à des spécificités matériels ( multiprocesseurs...) ou d'OS (
en incluant le type de bases de données : SQL SERVER 2005 "normal" ou Express
)
bb correspond à la correction de bugs importants ( genre Service Pack )
Revision : correspond à des modifications mineures ou des corrections de
bugs mineurs
Je sais que , autrefois, pour Microsoft, le build correspondait à la date
de compilation en format YYYYMMDD et le revision à l'heure de compilation en
format HHMMSS
Personnellement, ma propre définition du build/revision ne me satisfait pas
et si quelqu'un pouvait trouver une autre définition, cela me rendrait bien
service
Bonne journée
"Gilles TOURREAU" a écrit :papy normand a exprimé avec précision :Bonjour,
un numéro de version se divise en 4 parties ( de gauche à droite)
major
minor
build
revision
la règle ( en général ) est la suivante :
- on ne change le major et/ou minor que dans le cas où la nouvelle version
est incompatible avec la précédente
- on change le build lors de modifications compatibles avec la version
précédente mais apportant des fonctionnalités nouvelles
- on change le revision lors d'une recompilation après des modifications
peu importantes ( amélioration d'interfaces ou correction de bugs mineurs
sur des fonctionnalités peu utilisées )
On considère que 2 versions sont identiques si le build est le même
C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
En espérant avoir pu vous renseigner
Bonne journée
"Gilles TOURREAU" a écrit :Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Merci pour cette réponse claire, nette et précise !
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour,
j'ai retrouvé ceci dans la définition de la propriété Version sur MSDN
adresse : http://msdn2.microsoft.com/en-us/library/system.version.aspx
Version numbers consist of two to four components: major, minor, build, and
revision. The major and minor components are required; the build and revision
components are optional, but the build component is required if the revision
component is defined. All defined components must be integers greater than or
equal to 0. The format of the version number is as follows. Optional
components are shown in square brackets ('[' and ']'):
major.minor[.build[.revision]]
The components are used by convention as follows:
Major : Assemblies with the same name but different major versions are not
interchangeable. This would be appropriate, for example, for a major rewrite
of a product where backward compatibility cannot be assumed.
Minor : If the name and major number on two assemblies are the same, but the
minor number is different, this indicates significant enhancement with the
intention of backward compatibility. This would be appropriate, for example,
on a point release of a product or a fully backward compatible new version of
a product.
Build : A difference in build number represents a recompilation of the same
source. This would be appropriate because of processor, platform, or compiler
changes.
Revision : Assemblies with the same name, major, and minor version numbers
but different revisions are intended to be fully interchangeable. This would
be appropriate to fix a security hole in a previously released assembly.
Subsequent versions of an assembly that differ only by build or revision
numbers are considered to be Hotfix updates of the prior version.
Starting with .NET Framework 2.0, the MajorRevision and MinorRevision
properties enable you to identify a temporary version of your application
that, for example, corrects a problem until you can release a permanent
solution. Furthermore, the Windows NT operating system uses the MajorRevision
property to encode the service pack number.
Ce qui n'est pas forcément très clair.
Pour mes propres dèveloppements, j'applique les règles suivantes :
Major : pour le moment, toujours à 1
Minor : pour le moment, toujours à 1 ( mais correspondrait à d'importantes
modifications dans les fonctionnalités ou à un changement de version du
Framework)
Build : sous la forme aabb
aa correspond à des spécificités matériels ( multiprocesseurs...) ou d'OS (
en incluant le type de bases de données : SQL SERVER 2005 "normal" ou Express
)
bb correspond à la correction de bugs importants ( genre Service Pack )
Revision : correspond à des modifications mineures ou des corrections de
bugs mineurs
Je sais que , autrefois, pour Microsoft, le build correspondait à la date
de compilation en format YYYYMMDD et le revision à l'heure de compilation en
format HHMMSS
Personnellement, ma propre définition du build/revision ne me satisfait pas
et si quelqu'un pouvait trouver une autre définition, cela me rendrait bien
service
Bonne journée
"Gilles TOURREAU" a écrit :
papy normand a exprimé avec précision :
Bonjour,
un numéro de version se divise en 4 parties ( de gauche à droite)
major
minor
build
revision
la règle ( en général ) est la suivante :
- on ne change le major et/ou minor que dans le cas où la nouvelle version
est incompatible avec la précédente
- on change le build lors de modifications compatibles avec la version
précédente mais apportant des fonctionnalités nouvelles
- on change le revision lors d'une recompilation après des modifications
peu importantes ( amélioration d'interfaces ou correction de bugs mineurs
sur des fonctionnalités peu utilisées )
On considère que 2 versions sont identiques si le build est le même
C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
En espérant avoir pu vous renseigner
Bonne journée
"Gilles TOURREAU" a écrit :
Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Merci pour cette réponse claire, nette et précise !
Cordialement
--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Bonjour,
j'ai retrouvé ceci dans la définition de la propriété Version sur MSDN
adresse : http://msdn2.microsoft.com/en-us/library/system.version.aspx
Version numbers consist of two to four components: major, minor, build, and
revision. The major and minor components are required; the build and revision
components are optional, but the build component is required if the revision
component is defined. All defined components must be integers greater than or
equal to 0. The format of the version number is as follows. Optional
components are shown in square brackets ('[' and ']'):
major.minor[.build[.revision]]
The components are used by convention as follows:
Major : Assemblies with the same name but different major versions are not
interchangeable. This would be appropriate, for example, for a major rewrite
of a product where backward compatibility cannot be assumed.
Minor : If the name and major number on two assemblies are the same, but the
minor number is different, this indicates significant enhancement with the
intention of backward compatibility. This would be appropriate, for example,
on a point release of a product or a fully backward compatible new version of
a product.
Build : A difference in build number represents a recompilation of the same
source. This would be appropriate because of processor, platform, or compiler
changes.
Revision : Assemblies with the same name, major, and minor version numbers
but different revisions are intended to be fully interchangeable. This would
be appropriate to fix a security hole in a previously released assembly.
Subsequent versions of an assembly that differ only by build or revision
numbers are considered to be Hotfix updates of the prior version.
Starting with .NET Framework 2.0, the MajorRevision and MinorRevision
properties enable you to identify a temporary version of your application
that, for example, corrects a problem until you can release a permanent
solution. Furthermore, the Windows NT operating system uses the MajorRevision
property to encode the service pack number.
Ce qui n'est pas forcément très clair.
Pour mes propres dèveloppements, j'applique les règles suivantes :
Major : pour le moment, toujours à 1
Minor : pour le moment, toujours à 1 ( mais correspondrait à d'importantes
modifications dans les fonctionnalités ou à un changement de version du
Framework)
Build : sous la forme aabb
aa correspond à des spécificités matériels ( multiprocesseurs...) ou d'OS (
en incluant le type de bases de données : SQL SERVER 2005 "normal" ou Express
)
bb correspond à la correction de bugs importants ( genre Service Pack )
Revision : correspond à des modifications mineures ou des corrections de
bugs mineurs
Je sais que , autrefois, pour Microsoft, le build correspondait à la date
de compilation en format YYYYMMDD et le revision à l'heure de compilation en
format HHMMSS
Personnellement, ma propre définition du build/revision ne me satisfait pas
et si quelqu'un pouvait trouver une autre définition, cela me rendrait bien
service
Bonne journée
"Gilles TOURREAU" a écrit :papy normand a exprimé avec précision :Bonjour,
un numéro de version se divise en 4 parties ( de gauche à droite)
major
minor
build
revision
la règle ( en général ) est la suivante :
- on ne change le major et/ou minor que dans le cas où la nouvelle version
est incompatible avec la précédente
- on change le build lors de modifications compatibles avec la version
précédente mais apportant des fonctionnalités nouvelles
- on change le revision lors d'une recompilation après des modifications
peu importantes ( amélioration d'interfaces ou correction de bugs mineurs
sur des fonctionnalités peu utilisées )
On considère que 2 versions sont identiques si le build est le même
C'est la règle utilisée par Microsoft pour l'ensemble de ses logiciels.
En espérant avoir pu vous renseigner
Bonne journée
"Gilles TOURREAU" a écrit :Bonjour tout le monde !
Une question plus d'organisation que technique :
Les numéros de version de .NET sont composées de 4 nombres.
Les 2 premiers représentent la version mineur et majeur d'un assembly.
Le 4ème, la correction d'un bug.
Mais que représente exactement le 3ème (build) ? Quand faut-il vraiment
l'incrementer ?
En vous remerciant par avance de vos lumières...
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Merci pour cette réponse claire, nette et précise !
Cordialement
--
Gilles TOURREAU
Responsable informatique
Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
En effet si l'on écrit la version comme ceci : 1.0.* dans
l'AssemblyInfo.cs on a :
Le n° de révision qui correspond alors au nombre de minute depuis minuit
et la compilation.
Le n° de build qui correspond au nombre de jour depuis l'an 2000 (je
crois).
Mais je trouve que ce procédé crée des n° trop long et difficile à
manier...
Je vais adopter la méthode que vous m'avez communiqué au premier post
qui est :
incrémenter le n° de build pour des petites corrections (ces petites
corrections de doivent pas changer la compatibilité avec d'autres
assembly).
incrémenter le n° de révision pour des grandes corrections, changement
de structure de la base de données, suppression d'une fonction
public/protected ou modification d'un paramètre d'une fonction
public/protected (qui impacte forcement d'autres assembly).
En effet si l'on écrit la version comme ceci : 1.0.* dans
l'AssemblyInfo.cs on a :
Le n° de révision qui correspond alors au nombre de minute depuis minuit
et la compilation.
Le n° de build qui correspond au nombre de jour depuis l'an 2000 (je
crois).
Mais je trouve que ce procédé crée des n° trop long et difficile à
manier...
Je vais adopter la méthode que vous m'avez communiqué au premier post
qui est :
incrémenter le n° de build pour des petites corrections (ces petites
corrections de doivent pas changer la compatibilité avec d'autres
assembly).
incrémenter le n° de révision pour des grandes corrections, changement
de structure de la base de données, suppression d'une fonction
public/protected ou modification d'un paramètre d'une fonction
public/protected (qui impacte forcement d'autres assembly).
En effet si l'on écrit la version comme ceci : 1.0.* dans
l'AssemblyInfo.cs on a :
Le n° de révision qui correspond alors au nombre de minute depuis minuit
et la compilation.
Le n° de build qui correspond au nombre de jour depuis l'an 2000 (je
crois).
Mais je trouve que ce procédé crée des n° trop long et difficile à
manier...
Je vais adopter la méthode que vous m'avez communiqué au premier post
qui est :
incrémenter le n° de build pour des petites corrections (ces petites
corrections de doivent pas changer la compatibilité avec d'autres
assembly).
incrémenter le n° de révision pour des grandes corrections, changement
de structure de la base de données, suppression d'une fonction
public/protected ou modification d'un paramètre d'une fonction
public/protected (qui impacte forcement d'autres assembly).
