Nous avons l'intention d'ouvrir une forge pour créer un composant
WD-Tools,
à l'image de ce qui existait sous Clipper, le CA-Tools.
Ce composant, en licence WD-Libre pour la version compilée, regrouperait
une
série de fonctions, procédures, classes ou autres éléments (Modèles de
champs, de fenêtre, etc.) d'intérêt général.
Les contributeurs auraient accès, en lecture seule, à l'ensemble des
sources, et à en écriture pour toutes leurs contributions.
Cette forge (un GDS) serait hébergé sur le serveur Be-Dev et serait
accessible via Internet.
Nous avons l'intention d'ouvrir une forge pour créer un composant
WD-Tools,
à l'image de ce qui existait sous Clipper, le CA-Tools.
Ce composant, en licence WD-Libre pour la version compilée, regrouperait
une
série de fonctions, procédures, classes ou autres éléments (Modèles de
champs, de fenêtre, etc.) d'intérêt général.
Les contributeurs auraient accès, en lecture seule, à l'ensemble des
sources, et à en écriture pour toutes leurs contributions.
Cette forge (un GDS) serait hébergé sur le serveur Be-Dev et serait
accessible via Internet.
Nous avons l'intention d'ouvrir une forge pour créer un composant
WD-Tools,
à l'image de ce qui existait sous Clipper, le CA-Tools.
Ce composant, en licence WD-Libre pour la version compilée, regrouperait
une
série de fonctions, procédures, classes ou autres éléments (Modèles de
champs, de fenêtre, etc.) d'intérêt général.
Les contributeurs auraient accès, en lecture seule, à l'ensemble des
sources, et à en écriture pour toutes leurs contributions.
Cette forge (un GDS) serait hébergé sur le serveur Be-Dev et serait
accessible via Internet.
Cette forge (un GDS) serait hébergé sur le serveur Be-Dev et serait
accessible via Internet.
Donc vous bloquez uniquement pour la version en cours de WinDev.
Cette forge (un GDS) serait hébergé sur le serveur Be-Dev et serait
accessible via Internet.
Donc vous bloquez uniquement pour la version en cours de WinDev.
Cette forge (un GDS) serait hébergé sur le serveur Be-Dev et serait
accessible via Internet.
Donc vous bloquez uniquement pour la version en cours de WinDev.
Salut Emmanuel, Salut Romain,
Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans WDTools
...
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent encore
avec des versions antérieures à la version en cours ?
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets) et surtout une évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Salut Emmanuel, Salut Romain,
Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans WDTools
...
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent encore
avec des versions antérieures à la version en cours ?
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets) et surtout une évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Salut Emmanuel, Salut Romain,
Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans WDTools
...
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent encore
avec des versions antérieures à la version en cours ?
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets) et surtout une évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
vient de nous annoncer :Salut Emmanuel, Salut Romain,
Bonjour,Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
composant qui regrouperait 100 fonctions mais dont 1 seule serait utilisée.
Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
préfère nettement avoir la possibilité de piocher.
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans WDTools
...
Ils ont effectivement déjà fait cela par le passé...
Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
encore
avec des versions antérieures à la version en cours ?
Aucune idée, je sais juste que c'est mon cas.
(et d'ailleurs j'ai encore des applis en WD5.5).
Je remarque juste qu'un code source en licence libre a plus de crédit
quand il est disponible en clair (en texte) qu'en binaire uniquement
lisible avec une version particulièrte d'un outil.
Je trouve dommage par exemple, qu'avec votre solution, on ne puisse pas
disposer du code pour adapter à sa convenance des fonctions qui seraient
particulièrement intéressantes pour un projet développé en version
inférieure à la version en cours de l'outil.
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets) et surtout une
évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Mon expérience me montre qu'au contraire on peut se passer assez bien et
pendant des années, de gagdets marketing.
A+
marcel.berman@managingbusiness.be vient de nous annoncer :
Salut Emmanuel, Salut Romain,
Bonjour,
Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
composant qui regrouperait 100 fonctions mais dont 1 seule serait utilisée.
Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
préfère nettement avoir la possibilité de piocher.
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans WDTools
...
Ils ont effectivement déjà fait cela par le passé...
Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
encore
avec des versions antérieures à la version en cours ?
Aucune idée, je sais juste que c'est mon cas.
(et d'ailleurs j'ai encore des applis en WD5.5).
Je remarque juste qu'un code source en licence libre a plus de crédit
quand il est disponible en clair (en texte) qu'en binaire uniquement
lisible avec une version particulièrte d'un outil.
Je trouve dommage par exemple, qu'avec votre solution, on ne puisse pas
disposer du code pour adapter à sa convenance des fonctions qui seraient
particulièrement intéressantes pour un projet développé en version
inférieure à la version en cours de l'outil.
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets) et surtout une
évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Mon expérience me montre qu'au contraire on peut se passer assez bien et
pendant des années, de gagdets marketing.
A+
vient de nous annoncer :Salut Emmanuel, Salut Romain,
Bonjour,Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
composant qui regrouperait 100 fonctions mais dont 1 seule serait utilisée.
Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
préfère nettement avoir la possibilité de piocher.
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans WDTools
...
Ils ont effectivement déjà fait cela par le passé...
Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
encore
avec des versions antérieures à la version en cours ?
Aucune idée, je sais juste que c'est mon cas.
(et d'ailleurs j'ai encore des applis en WD5.5).
Je remarque juste qu'un code source en licence libre a plus de crédit
quand il est disponible en clair (en texte) qu'en binaire uniquement
lisible avec une version particulièrte d'un outil.
Je trouve dommage par exemple, qu'avec votre solution, on ne puisse pas
disposer du code pour adapter à sa convenance des fonctions qui seraient
particulièrement intéressantes pour un projet développé en version
inférieure à la version en cours de l'outil.
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets) et surtout une
évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Mon expérience me montre qu'au contraire on peut se passer assez bien et
pendant des années, de gagdets marketing.
A+
Romain PETIT a écrit :vient de nous annoncer :Salut Emmanuel, Salut Romain,
Bonjour,Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
composant qui regrouperait 100 fonctions mais dont 1 seule serait
utilisée.
Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
préfère nettement avoir la possibilité de piocher.
+1. Surtout que je ne sois pas sûr que Windev, contrairement à d'autres
compilateur, ne garde que ce qui est utilisé dans l'exe final.Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans
WDTools
...
Ils ont effectivement déjà fait cela par le passé...
Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
C'est du pillage, non ?Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
encore
avec des versions antérieures à la version en cours ?
Aucune idée, je sais juste que c'est mon cas.
(et d'ailleurs j'ai encore des applis en WD5.5).
Je remarque juste qu'un code source en licence libre a plus de crédit
quand il est disponible en clair (en texte) qu'en binaire uniquement
lisible avec une version particulièrte d'un outil.
Perso, c'est WD5.5 et WD10
Je trouve dommage par exemple, qu'avec votre solution, on ne puisse
pas disposer du code pour adapter à sa convenance des fonctions qui
seraient particulièrement intéressantes pour un projet développé en
version inférieure à la version en cours de l'outil.
+1000Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets)
et surtout une
évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Mon expérience me montre qu'au contraire on peut se passer assez bien
et pendant des années, de gagdets marketing.
Pas mieux :-)
A+
Romain PETIT a écrit :
marcel.berman@managingbusiness.be vient de nous annoncer :
Salut Emmanuel, Salut Romain,
Bonjour,
Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
composant qui regrouperait 100 fonctions mais dont 1 seule serait
utilisée.
Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
préfère nettement avoir la possibilité de piocher.
+1. Surtout que je ne sois pas sûr que Windev, contrairement à d'autres
compilateur, ne garde que ce qui est utilisé dans l'exe final.
Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans
WDTools
...
Ils ont effectivement déjà fait cela par le passé...
Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
C'est du pillage, non ?
Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
encore
avec des versions antérieures à la version en cours ?
Aucune idée, je sais juste que c'est mon cas.
(et d'ailleurs j'ai encore des applis en WD5.5).
Je remarque juste qu'un code source en licence libre a plus de crédit
quand il est disponible en clair (en texte) qu'en binaire uniquement
lisible avec une version particulièrte d'un outil.
Perso, c'est WD5.5 et WD10
Je trouve dommage par exemple, qu'avec votre solution, on ne puisse
pas disposer du code pour adapter à sa convenance des fonctions qui
seraient particulièrement intéressantes pour un projet développé en
version inférieure à la version en cours de l'outil.
+1000
Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets)
et surtout une
évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Mon expérience me montre qu'au contraire on peut se passer assez bien
et pendant des années, de gagdets marketing.
Pas mieux :-)
A+
Romain PETIT a écrit :vient de nous annoncer :Salut Emmanuel, Salut Romain,
Bonjour,Le but du (des) composant(s) WDTools serait de regrouper toutes ces
fonctions afin de mettre à disposition du plus grand nombre les trucs et
astuces des contributeurs.
Pourquoi demander à chacun de réinventer la roue ?
Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
composant qui regrouperait 100 fonctions mais dont 1 seule serait
utilisée.
Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
préfère nettement avoir la possibilité de piocher.
+1. Surtout que je ne sois pas sûr que Windev, contrairement à d'autres
compilateur, ne garde que ce qui est utilisé dans l'exe final.Je suis persuadé que si PC-Soft trouve l'une des fonctions intéressante,
elle sera intégrée dans une version ultérieure du language, mais cela ne
fera que souligner la pertinence du fait de l'avoir intégrée dans
WDTools
...
Ils ont effectivement déjà fait cela par le passé...
Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
C'est du pillage, non ?Reste le fait que le composant ne sera utilisable qu'avec des versions
récentes de l'outil ...
Franchement, je ne sais pas si c'est réellement un problème.
Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
encore
avec des versions antérieures à la version en cours ?
Aucune idée, je sais juste que c'est mon cas.
(et d'ailleurs j'ai encore des applis en WD5.5).
Je remarque juste qu'un code source en licence libre a plus de crédit
quand il est disponible en clair (en texte) qu'en binaire uniquement
lisible avec une version particulièrte d'un outil.
Perso, c'est WD5.5 et WD10
Je trouve dommage par exemple, qu'avec votre solution, on ne puisse
pas disposer du code pour adapter à sa convenance des fonctions qui
seraient particulièrement intéressantes pour un projet développé en
version inférieure à la version en cours de l'outil.
+1000Franchement, mon expérience me montre qu'il est toujours avantageux de
passer aux nouvelles versions (avec un petit temps de latence afin de
laisser la nouvelle version faire sa maladie), car en général, elles
apportent souvent de nouvelles possibilités intéressantes (pas
nécessairement pour tout le monde, je l'admets)
et surtout une
évolution du
désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
concurrencer quelques ténors du marché dans bien des usages.
Mon expérience me montre qu'au contraire on peut se passer assez bien
et pendant des années, de gagdets marketing.
Pas mieux :-)
A+
Romain PETIT a écrit :
> vient de nous annoncer :
>> Salut Emmanuel, Salut Romain,
>
> Bonjour,
>
>> Le but du (des) composant(s) WDTools serait de regrouper toutes ces
>> fonctions afin de mettre à disposition du plus grand nombre les trucs
>> et
>> astuces des contributeurs.
>> Pourquoi demander à chacun de réinventer la roue ?
>
> Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
> composant qui regrouperait 100 fonctions mais dont 1 seule serait
> utilisée.
> Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
> préfère nettement avoir la possibilité de piocher.
+1. Surtout que je ne sois pas sûr que Windev, contrairement à d'autres
compilateur, ne garde que ce qui est utilisé dans l'exe final.
>
>> Je suis persuadé que si PC-Soft trouve l'une des fonctions
>> intéressante,
>> elle sera intégrée dans une version ultérieure du language, mais cela
>> ne
>> fera que souligner la pertinence du fait de l'avoir intégrée dans
>> WDTools
>> ...
>
> Ils ont effectivement déjà fait cela par le passé...
> Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
C'est du pillage, non ?
>
>> Reste le fait que le composant ne sera utilisable qu'avec des versions
>> récentes de l'outil ...
>> Franchement, je ne sais pas si c'est réellement un problème.
>> Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
>> encore
>> avec des versions antérieures à la version en cours ?
>
> Aucune idée, je sais juste que c'est mon cas.
> (et d'ailleurs j'ai encore des applis en WD5.5).
> Je remarque juste qu'un code source en licence libre a plus de crédit
> quand il est disponible en clair (en texte) qu'en binaire uniquement
> lisible avec une version particulièrte d'un outil.
Perso, c'est WD5.5 et WD10
>
> Je trouve dommage par exemple, qu'avec votre solution, on ne puisse pas
> disposer du code pour adapter à sa convenance des fonctions qui seraient
>
> particulièrement intéressantes pour un projet développé en version
> inférieure à la version en cours de l'outil.
+1000
>
>> Franchement, mon expérience me montre qu'il est toujours avantageux de
>> passer aux nouvelles versions (avec un petit temps de latence afin de
>> laisser la nouvelle version faire sa maladie), car en général, elles
>> apportent souvent de nouvelles possibilités intéressantes (pas
>> nécessairement pour tout le monde, je l'admets) et surtout une
>> évolution du
>> désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
>> concurrencer quelques ténors du marché dans bien des usages.
>
> Mon expérience me montre qu'au contraire on peut se passer assez bien et
>
> pendant des années, de gagdets marketing.
Pas mieux :-)
Romain PETIT a écrit :
> marcel.berman@managingbusiness.be vient de nous annoncer :
>> Salut Emmanuel, Salut Romain,
>
> Bonjour,
>
>> Le but du (des) composant(s) WDTools serait de regrouper toutes ces
>> fonctions afin de mettre à disposition du plus grand nombre les trucs
>> et
>> astuces des contributeurs.
>> Pourquoi demander à chacun de réinventer la roue ?
>
> Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
> composant qui regrouperait 100 fonctions mais dont 1 seule serait
> utilisée.
> Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
> préfère nettement avoir la possibilité de piocher.
+1. Surtout que je ne sois pas sûr que Windev, contrairement à d'autres
compilateur, ne garde que ce qui est utilisé dans l'exe final.
>
>> Je suis persuadé que si PC-Soft trouve l'une des fonctions
>> intéressante,
>> elle sera intégrée dans une version ultérieure du language, mais cela
>> ne
>> fera que souligner la pertinence du fait de l'avoir intégrée dans
>> WDTools
>> ...
>
> Ils ont effectivement déjà fait cela par le passé...
> Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
C'est du pillage, non ?
>
>> Reste le fait que le composant ne sera utilisable qu'avec des versions
>> récentes de l'outil ...
>> Franchement, je ne sais pas si c'est réellement un problème.
>> Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
>> encore
>> avec des versions antérieures à la version en cours ?
>
> Aucune idée, je sais juste que c'est mon cas.
> (et d'ailleurs j'ai encore des applis en WD5.5).
> Je remarque juste qu'un code source en licence libre a plus de crédit
> quand il est disponible en clair (en texte) qu'en binaire uniquement
> lisible avec une version particulièrte d'un outil.
Perso, c'est WD5.5 et WD10
>
> Je trouve dommage par exemple, qu'avec votre solution, on ne puisse pas
> disposer du code pour adapter à sa convenance des fonctions qui seraient
>
> particulièrement intéressantes pour un projet développé en version
> inférieure à la version en cours de l'outil.
+1000
>
>> Franchement, mon expérience me montre qu'il est toujours avantageux de
>> passer aux nouvelles versions (avec un petit temps de latence afin de
>> laisser la nouvelle version faire sa maladie), car en général, elles
>> apportent souvent de nouvelles possibilités intéressantes (pas
>> nécessairement pour tout le monde, je l'admets) et surtout une
>> évolution du
>> désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
>> concurrencer quelques ténors du marché dans bien des usages.
>
> Mon expérience me montre qu'au contraire on peut se passer assez bien et
>
> pendant des années, de gagdets marketing.
Pas mieux :-)
Romain PETIT a écrit :
> vient de nous annoncer :
>> Salut Emmanuel, Salut Romain,
>
> Bonjour,
>
>> Le but du (des) composant(s) WDTools serait de regrouper toutes ces
>> fonctions afin de mettre à disposition du plus grand nombre les trucs
>> et
>> astuces des contributeurs.
>> Pourquoi demander à chacun de réinventer la roue ?
>
> Ce qui me gène dans ce principe, c'est d'inclure dans un projet un
> composant qui regrouperait 100 fonctions mais dont 1 seule serait
> utilisée.
> Je ne vois pas trop l'intérêt de regrouper tout dans un seul item, je
> préfère nettement avoir la possibilité de piocher.
+1. Surtout que je ne sois pas sûr que Windev, contrairement à d'autres
compilateur, ne garde que ce qui est utilisé dans l'exe final.
>
>> Je suis persuadé que si PC-Soft trouve l'une des fonctions
>> intéressante,
>> elle sera intégrée dans une version ultérieure du language, mais cela
>> ne
>> fera que souligner la pertinence du fait de l'avoir intégrée dans
>> WDTools
>> ...
>
> Ils ont effectivement déjà fait cela par le passé...
> Ce qui me gène, c'est le (non)-respect de la licence WD-Libre.
C'est du pillage, non ?
>
>> Reste le fait que le composant ne sera utilisable qu'avec des versions
>> récentes de l'outil ...
>> Franchement, je ne sais pas si c'est réellement un problème.
>> Quelqu'un a-t'il une idée du nombre de développeurs qui travaillent
>> encore
>> avec des versions antérieures à la version en cours ?
>
> Aucune idée, je sais juste que c'est mon cas.
> (et d'ailleurs j'ai encore des applis en WD5.5).
> Je remarque juste qu'un code source en licence libre a plus de crédit
> quand il est disponible en clair (en texte) qu'en binaire uniquement
> lisible avec une version particulièrte d'un outil.
Perso, c'est WD5.5 et WD10
>
> Je trouve dommage par exemple, qu'avec votre solution, on ne puisse pas
> disposer du code pour adapter à sa convenance des fonctions qui seraient
>
> particulièrement intéressantes pour un projet développé en version
> inférieure à la version en cours de l'outil.
+1000
>
>> Franchement, mon expérience me montre qu'il est toujours avantageux de
>> passer aux nouvelles versions (avec un petit temps de latence afin de
>> laisser la nouvelle version faire sa maladie), car en général, elles
>> apportent souvent de nouvelles possibilités intéressantes (pas
>> nécessairement pour tout le monde, je l'admets) et surtout une
>> évolution du
>> désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
>> concurrencer quelques ténors du marché dans bien des usages.
>
> Mon expérience me montre qu'au contraire on peut se passer assez bien et
>
> pendant des années, de gagdets marketing.
Pas mieux :-)
Et c'est la raison pour laquelle nous offrons l'accès aux sources à tout les
contributeurs (en lecture seule, sauf leurs propres contributions qui
seront, évidemment en lecture/écriture).
Par contre, si nous trouvons logique de "distribuer" sous licence WD-Libre
(ou peut être une variante de celle-ci, car je l'avoue, je ne l'ai pas
examinée en profondeur), les "fonctionnalités", à savoir les composants, et
sachant que la majorité des utilisateurs ne contribueront pas à l'évolution
du schmilblik, nous trouvons que les contributeurs, eux, en remerciement de
leur(s) contribution(s), devraient pouvoir accéder à tous les sources et
ressources diverses du projet.
particulièrement intéressantes pour un projet développé en version
inférieure à la version en cours de l'outil.
+1000
Voir ma réponse ci-dessus, les contributeurs y ont accès ...
Et c'est la raison pour laquelle nous offrons l'accès aux sources à tout les
contributeurs (en lecture seule, sauf leurs propres contributions qui
seront, évidemment en lecture/écriture).
Par contre, si nous trouvons logique de "distribuer" sous licence WD-Libre
(ou peut être une variante de celle-ci, car je l'avoue, je ne l'ai pas
examinée en profondeur), les "fonctionnalités", à savoir les composants, et
sachant que la majorité des utilisateurs ne contribueront pas à l'évolution
du schmilblik, nous trouvons que les contributeurs, eux, en remerciement de
leur(s) contribution(s), devraient pouvoir accéder à tous les sources et
ressources diverses du projet.
particulièrement intéressantes pour un projet développé en version
inférieure à la version en cours de l'outil.
+1000
Voir ma réponse ci-dessus, les contributeurs y ont accès ...
Et c'est la raison pour laquelle nous offrons l'accès aux sources à tout les
contributeurs (en lecture seule, sauf leurs propres contributions qui
seront, évidemment en lecture/écriture).
Par contre, si nous trouvons logique de "distribuer" sous licence WD-Libre
(ou peut être une variante de celle-ci, car je l'avoue, je ne l'ai pas
examinée en profondeur), les "fonctionnalités", à savoir les composants, et
sachant que la majorité des utilisateurs ne contribueront pas à l'évolution
du schmilblik, nous trouvons que les contributeurs, eux, en remerciement de
leur(s) contribution(s), devraient pouvoir accéder à tous les sources et
ressources diverses du projet.
particulièrement intéressantes pour un projet développé en version
inférieure à la version en cours de l'outil.
+1000
Voir ma réponse ci-dessus, les contributeurs y ont accès ...
>> Franchement, mon expérience me montre qu'il est toujours avantageux de
>>> passer aux nouvelles versions (avec un petit temps de latence afin de
>>> laisser la nouvelle version faire sa maladie), car en général, elles
>>> apportent souvent de nouvelles possibilités intéressantes (pas
>>> nécessairement pour tout le monde, je l'admets)
Pour des nouveaux projets (ou des petits projets), oui, par contre on ne
touche pas un projet qui marche et il est toujours préférable de rester
sur des versions dont on connait le comportement.
>>>et surtout une
>>> évolution du
>>> désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
>>> concurrencer quelques ténors du marché dans bien des usages.
Qui Oracle, SQLServer, MySQL, Sybase, Ingres, Postgres ?
Que commercialement on tienne ce discours pour vendre une appli qu'on
développe sur HF, pourquoi pas. Mais en être convaincu techniquement
c'est me semble-t-il une autre histoire.
De plus commercialement si un client veut utiliser HF pour faire des
requêtes avec des outils tiers par exemple, il doit acheter une licence
Windev 1650 euros par machine hébergeant le moteur HF (c'est dans la
licence). C'est 3 à 4 fois plus que MySQL.
>> Franchement, mon expérience me montre qu'il est toujours avantageux de
>>> passer aux nouvelles versions (avec un petit temps de latence afin de
>>> laisser la nouvelle version faire sa maladie), car en général, elles
>>> apportent souvent de nouvelles possibilités intéressantes (pas
>>> nécessairement pour tout le monde, je l'admets)
Pour des nouveaux projets (ou des petits projets), oui, par contre on ne
touche pas un projet qui marche et il est toujours préférable de rester
sur des versions dont on connait le comportement.
>>>et surtout une
>>> évolution du
>>> désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
>>> concurrencer quelques ténors du marché dans bien des usages.
Qui Oracle, SQLServer, MySQL, Sybase, Ingres, Postgres ?
Que commercialement on tienne ce discours pour vendre une appli qu'on
développe sur HF, pourquoi pas. Mais en être convaincu techniquement
c'est me semble-t-il une autre histoire.
De plus commercialement si un client veut utiliser HF pour faire des
requêtes avec des outils tiers par exemple, il doit acheter une licence
Windev 1650 euros par machine hébergeant le moteur HF (c'est dans la
licence). C'est 3 à 4 fois plus que MySQL.
>> Franchement, mon expérience me montre qu'il est toujours avantageux de
>>> passer aux nouvelles versions (avec un petit temps de latence afin de
>>> laisser la nouvelle version faire sa maladie), car en général, elles
>>> apportent souvent de nouvelles possibilités intéressantes (pas
>>> nécessairement pour tout le monde, je l'admets)
Pour des nouveaux projets (ou des petits projets), oui, par contre on ne
touche pas un projet qui marche et il est toujours préférable de rester
sur des versions dont on connait le comportement.
>>>et surtout une
>>> évolution du
>>> désormais HF SQL (l'ancien HF C/S) qui me semble désormais pouvoir
>>> concurrencer quelques ténors du marché dans bien des usages.
Qui Oracle, SQLServer, MySQL, Sybase, Ingres, Postgres ?
Que commercialement on tienne ce discours pour vendre une appli qu'on
développe sur HF, pourquoi pas. Mais en être convaincu techniquement
c'est me semble-t-il une autre histoire.
De plus commercialement si un client veut utiliser HF pour faire des
requêtes avec des outils tiers par exemple, il doit acheter une licence
Windev 1650 euros par machine hébergeant le moteur HF (c'est dans la
licence). C'est 3 à 4 fois plus que MySQL.
Il faudra vous trouver une autre licence, c'est contraire à la
WD-Libre...
>>> particulièrement intéressantes pour un projet développé en version
>>> inférieure à la version en cours de l'outil.
>> +1000
> Voir ma réponse ci-dessus, les contributeurs y ont accès ...
Le principe d'un source "libre", c'est de ne pas restreindre l'accès du
code source aux seuls contributeurs...
A+
Il faudra vous trouver une autre licence, c'est contraire à la
WD-Libre...
>>> particulièrement intéressantes pour un projet développé en version
>>> inférieure à la version en cours de l'outil.
>> +1000
> Voir ma réponse ci-dessus, les contributeurs y ont accès ...
Le principe d'un source "libre", c'est de ne pas restreindre l'accès du
code source aux seuls contributeurs...
A+
Il faudra vous trouver une autre licence, c'est contraire à la
WD-Libre...
>>> particulièrement intéressantes pour un projet développé en version
>>> inférieure à la version en cours de l'outil.
>> +1000
> Voir ma réponse ci-dessus, les contributeurs y ont accès ...
Le principe d'un source "libre", c'est de ne pas restreindre l'accès du
code source aux seuls contributeurs...
A+