You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Reza <re...@yahoo.com.INVALID> on 2014/07/17 16:34:52 UTC
Jira
So I think I have all the components of the project here:
https://issues.apache.org/jira/plugins/servlet/project-config/DMAP/components
Ive added a few more tasks to the list this morning. In particular, I created an Epic to capture the W3C tasks since there will be several:
https://issues.apache.org/jira/browse/DMAP-49
As for versions, not sure if there is a way to give different components their own versioning scheme. The reason being is that im not sure its going to be practical to keep all the components on the same versioning. Its important to try and track tasks with versions (ie: a roadmap), so maybe we label the version with its component, ex: 1.1 (java-client), 1.1 (data), 1.5 (browsermap)
Re: Jira
Posted by Werner Keil <we...@gmail.com>.
On Thu, Jul 17, 2014 at 5:07 PM, Reza <re...@yahoo.com.invalid>
wrote:
> >> Do we need extra zeros here like 1.1.x or are 2 digits enough?
>
> Depends on how we want to version. So generally the first digit is major,
> the second minor, and the 3rd maintenance. If this goes against a standard,
> please enlighten me :)
>
>
I suppose there is more especially those Eberhard mentioned from the .NET
side, but we can probably stick to 3.
> So new features go into minor releases and major features, changes, etc,
> go into a major. Or if we think the product has changed enough to warrant a
> major release, bump up the version.
>
> Ex: 1.1 is a typical feature release, 2.0 is a big release. 1.2.1 is a
> maintenance release for 1.2.
>
> So yes, we can track the full release numbers. Just depends on how we want
> to manage versions.
>
For JIRA 2 could be enough if everyone is happy, but then the question not
just for BrowserMap is, what we put before the "-SNAPSHOT"?
Until a fully interactive user-driven device data gathering can be rolled
out, changes there would normally be in a maintenance release scale, too.
Either based on user feedback (JIRA) or extra sources like OpenDDR where
that changes on GitHub.
So if device data is updated, the next build would be 1.0.1, should there
be daily or Web Service driven changes, maybe an extra digit was even a
good idea...
>
> Thoughts?
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> Sent: Thursday, July 17, 2014 10:48 AM
> Subject: Re: Jira
>
>
> Do we need extra zeros here like 1.1.x or are 2 digits enough?
>
> Any component or POM module in TRUNK that was tagged and expects changes in
> the coming days or hours please don't forget to raise the version number in
> the subsequent POMs to
> either 1.1.0-SNAPSHOT or 1.0.1-SNAPSHOT (that depends on how we want to
> increase the next number) as well as 1.5.0-SNAPSHOT or 1.4.2-SNAPSHOT for
> browsermap.
>
> Thanks,
> Werner
>
>
> On Thu, Jul 17, 2014 at 4:34 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> > So I think I have all the components of the project here:
> >
> >
> >
> https://issues.apache.org/jira/plugins/servlet/project-config/DMAP/components
> >
> >
> > Ive added a few more tasks to the list this morning. In particular, I
> > created an Epic to capture the W3C tasks since there will be several:
> >
> > https://issues.apache.org/jira/browse/DMAP-49
> >
> >
> > As for versions, not sure if there is a way to give different components
> > their own versioning scheme. The reason being is that im not sure its
> going
> > to be practical to keep all the components on the same versioning. Its
> > important to try and track tasks with versions (ie: a roadmap), so maybe
> we
> > label the version with its component, ex: 1.1 (java-client), 1.1 (data),
> > 1.5 (browsermap)
> >
>
Re: Jira
Posted by "eberhard speer jr." <se...@ducis.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I fail to recall when I wrote such a thing !
esjr
On 17/07/2014 18:28, Werner Keil wrote:
> but as Eberhard mentioned before those platforms are not known to
> be very Open Source friendly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTx+yCAAoJEOxywXcFLKYcf9oH/A/8SKAi2vtwGol7eeI9z7v0
7RJzu5tTgB92OU3KrHPhRvzkPK/jjITX+3hxIYxZKwKts8LCB/yxFzJfxueZvZhv
7q1aH/ck82XDB3mT4BHz/ZPtidB1QVoIDSWItsTTPlpCtnpNwa3Gn8jRsGY2mszz
N7FMwVJ50y2FKYqAhyWciK/k1Qv3sFFd9WMUukRrCvcB+yzp4h81DzS7cTBrwNjV
P83EM6eNVvew/KkcrLoU0l8YQDKk9VlNdupNiMXoWXPgTp/NVmF4oTZGAPG3YyL/
6B8lm6MFz7F8MvdoV3hDbX5vS3NAt4y9m/XsGVqkMIX2CPmTLeSOzB/iehVLCX0=
=1MwN
-----END PGP SIGNATURE-----
Re: Jira
Posted by Werner Keil <we...@gmail.com>.
It may not publish anything to "Apache Snapshot" repo as it is set up right
now, but we have a Jenkins that continuously builds trunk of several
projects.
If any of them differs by more than just fixing a typo it should no longer
be called "1.0.0" as it is now, otherwise the content of the JAR or other
files generated would be different from the official 1.0.0 release.
On Thu, Jul 17, 2014 at 5:52 PM, Reza <re...@yahoo.com.invalid>
wrote:
> Right, if we do CI where our artifacts are being automatically published
> for other devs or to a larger audience, then it would be appropriate to
> label the release with a SNAPSHOT as to not get confused with an official
> release. I dont think this effects versioning in general, its more like
> what Bertrand said, "work in progress".
>
>
> http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it
>
>
>
> ________________________________
> From: Bertrand Delacretaz <bd...@apache.org>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Thursday, July 17, 2014 11:36 AM
> Subject: Re: Jira
>
>
> On Thu, Jul 17, 2014 at 5:28 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > The document does not seem to use the "-SNAPSHOT" notion...
> >
>
> Semantic versioning is meant for modules which are released - it is of
> course fine to use -SNAPSHOT for work in progress.
>
>
> -Bertrand
>
Re: Jira
Posted by Reza <re...@yahoo.com.INVALID>.
Right, if we do CI where our artifacts are being automatically published for other devs or to a larger audience, then it would be appropriate to label the release with a SNAPSHOT as to not get confused with an official release. I dont think this effects versioning in general, its more like what Bertrand said, "work in progress".
http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it
________________________________
From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Thursday, July 17, 2014 11:36 AM
Subject: Re: Jira
On Thu, Jul 17, 2014 at 5:28 PM, Werner Keil <we...@gmail.com> wrote:
> The document does not seem to use the "-SNAPSHOT" notion...
>
Semantic versioning is meant for modules which are released - it is of
course fine to use -SNAPSHOT for work in progress.
-Bertrand
Re: Jira
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 17, 2014 at 5:28 PM, Werner Keil <we...@gmail.com> wrote:
> The document does not seem to use the "-SNAPSHOT" notion...
>
Semantic versioning is meant for modules which are released - it is of
course fine to use -SNAPSHOT for work in progress.
-Bertrand
Re: Jira
Posted by Werner Keil <we...@gmail.com>.
The document does not seem to use the "-SNAPSHOT" notion, but it's fairly
common at least in the Maven/Gradle universe (not sure about Windows and
.NET, but as Eberhard mentioned before those platforms are not known to be
very Open Source friendly[?])
Werner
On Thu, Jul 17, 2014 at 5:23 PM, Werner Keil <we...@gmail.com> wrote:
> Funny, that there are other (though with a double-name) people than Oskar
> Werner with this last name[?]
>
> As there's no German version of the semserver project, it seems he's not
> of German speaking origin, at least not 1st or 2nd generation[?]
>
> On Thu, Jul 17, 2014 at 5:16 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> On Thu, Jul 17, 2014 at 5:07 PM, Reza <re...@yahoo.com.invalid>
>> wrote:
>> >...So generally the first digit is major, the second minor, and the 3rd
>> maintenance...
>>
>> http://semver.org/ has even more precise definitions of that - it is
>> what we are using (at least trying to) in the OSGi projects that I'm
>> involved in.
>>
>> -Bertrand
>>
>
>
Re: Jira
Posted by Werner Keil <we...@gmail.com>.
Funny, that there are other (though with a double-name) people than Oskar
Werner with this last name[?]
As there's no German version of the semserver project, it seems he's not of
German speaking origin, at least not 1st or 2nd generation[?]
On Thu, Jul 17, 2014 at 5:16 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thu, Jul 17, 2014 at 5:07 PM, Reza <re...@yahoo.com.invalid>
> wrote:
> >...So generally the first digit is major, the second minor, and the 3rd
> maintenance...
>
> http://semver.org/ has even more precise definitions of that - it is
> what we are using (at least trying to) in the OSGi projects that I'm
> involved in.
>
> -Bertrand
>
Re: Jira
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 17, 2014 at 5:07 PM, Reza <re...@yahoo.com.invalid> wrote:
>...So generally the first digit is major, the second minor, and the 3rd maintenance...
http://semver.org/ has even more precise definitions of that - it is
what we are using (at least trying to) in the OSGi projects that I'm
involved in.
-Bertrand
Re: Jira
Posted by Reza <re...@yahoo.com.INVALID>.
>> Do we need extra zeros here like 1.1.x or are 2 digits enough?
Depends on how we want to version. So generally the first digit is major, the second minor, and the 3rd maintenance. If this goes against a standard, please enlighten me :)
So new features go into minor releases and major features, changes, etc, go into a major. Or if we think the product has changed enough to warrant a major release, bump up the version.
Ex: 1.1 is a typical feature release, 2.0 is a big release. 1.2.1 is a maintenance release for 1.2.
So yes, we can track the full release numbers. Just depends on how we want to manage versions.
Thoughts?
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
Sent: Thursday, July 17, 2014 10:48 AM
Subject: Re: Jira
Do we need extra zeros here like 1.1.x or are 2 digits enough?
Any component or POM module in TRUNK that was tagged and expects changes in
the coming days or hours please don't forget to raise the version number in
the subsequent POMs to
either 1.1.0-SNAPSHOT or 1.0.1-SNAPSHOT (that depends on how we want to
increase the next number) as well as 1.5.0-SNAPSHOT or 1.4.2-SNAPSHOT for
browsermap.
Thanks,
Werner
On Thu, Jul 17, 2014 at 4:34 PM, Reza <re...@yahoo.com.invalid>
wrote:
> So I think I have all the components of the project here:
>
>
> https://issues.apache.org/jira/plugins/servlet/project-config/DMAP/components
>
>
> Ive added a few more tasks to the list this morning. In particular, I
> created an Epic to capture the W3C tasks since there will be several:
>
> https://issues.apache.org/jira/browse/DMAP-49
>
>
> As for versions, not sure if there is a way to give different components
> their own versioning scheme. The reason being is that im not sure its going
> to be practical to keep all the components on the same versioning. Its
> important to try and track tasks with versions (ie: a roadmap), so maybe we
> label the version with its component, ex: 1.1 (java-client), 1.1 (data),
> 1.5 (browsermap)
>
Re: Jira
Posted by Werner Keil <we...@gmail.com>.
Do we need extra zeros here like 1.1.x or are 2 digits enough?
Any component or POM module in TRUNK that was tagged and expects changes in
the coming days or hours please don't forget to raise the version number in
the subsequent POMs to
either 1.1.0-SNAPSHOT or 1.0.1-SNAPSHOT (that depends on how we want to
increase the next number) as well as 1.5.0-SNAPSHOT or 1.4.2-SNAPSHOT for
browsermap.
Thanks,
Werner
On Thu, Jul 17, 2014 at 4:34 PM, Reza <re...@yahoo.com.invalid>
wrote:
> So I think I have all the components of the project here:
>
>
> https://issues.apache.org/jira/plugins/servlet/project-config/DMAP/components
>
>
> Ive added a few more tasks to the list this morning. In particular, I
> created an Epic to capture the W3C tasks since there will be several:
>
> https://issues.apache.org/jira/browse/DMAP-49
>
>
> As for versions, not sure if there is a way to give different components
> their own versioning scheme. The reason being is that im not sure its going
> to be practical to keep all the components on the same versioning. Its
> important to try and track tasks with versions (ie: a roadmap), so maybe we
> label the version with its component, ex: 1.1 (java-client), 1.1 (data),
> 1.5 (browsermap)
>