I don't think we have to be super rigid, just have a general principle. If
a case comes up, we can consider deviations then, rather than form fixed
rules from hypothetical scenarios and then be bound by them.
Something like RFC-style SHOULD - a component release may deviate from the
general rule,
On Wed, 30 Nov 2016 10:23:37 +, Stian Soiland-Reyes wrote:
Yeah, that could be the better way, with a branched off commit for
the
"shrunk" project with a smaller list in the parent, then no
particular flags are needed to build from the resulting tag or source
repo.
I initially planned to
Yeah, that could be the better way, with a branched off commit for the
"shrunk" project with a smaller list in the parent, then no
particular flags are needed to build from the resulting tag or source repo.
I initially planned to do so within the Taverna project (before we moved to
ASF), as it co
On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
What if a feature was added to the maven-release-plugin to release a
subset
of submodules? I wonder how feasible that would be.
When I thought of independent module releases, I assumed that
it would just be a matter of excluding some of th
What if a feature was added to the maven-release-plugin to release a subset
of submodules? I wonder how feasible that would be.
On 28 November 2016 at 19:00, Jörg Schaible wrote:
> Gilles wrote:
>
> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
> >> Gilles,
> >>
> >> If you try to do this
Gilles wrote:
> On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>> Gilles,
>>
>> If you try to do this you are going to get very frustrated with
>> Maven. You cannot use the Maven Release plugin if all the versions
>> are
>> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
>>
On Mon, Nov 28, 2016 at 2:57 PM, Gilles
wrote:
> On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>
>> Gilles,
>>
>> If you try to do this you are going to get very frustrated with
>> Maven. You cannot use the Maven Release plugin if all the versions are
>> not SNAPSHOTs, and if they always have
On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
Gilles,
If you try to do this you are going to get very frustrated with
Maven. You cannot use the Maven Release plugin if all the versions
are
not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
little sense to have them be out
Gilles,
If you try to do this you are going to get very frustrated with Maven. You
cannot use the Maven Release plugin if all the versions are not SNAPSHOTs, and
if they always have to be SNAPSHOTs it makes very little sense to have them be
out of sync. If you don’t use the release plugin then
On Sun, 27 Nov 2016 20:35:51 -0600, Matt Sicker wrote:
Here's an example of a confusing versioning situation:
1. commons-foo-base version 1.1 is released
2. commons-foo-utils is still at version 1.0 as no code was updated.
Do you
release a 1.0.1 with a dependency update on commons-foo-base 1.1
Here's an example of a confusing versioning situation:
1. commons-foo-base version 1.1 is released
2. commons-foo-utils is still at version 1.0 as no code was updated. Do you
release a 1.0.1 with a dependency update on commons-foo-base 1.1, or do you
go with version 1.1 to match, or do you not eve
[...]
Let's keep in mind the context here: This is a component in Apache
Commons,
not a TLP. Therefore, IMO, we should match user's expectations of
simplicity, which is one repo and version for the component,
multi-module
or not, just like all of the other Apache Commons components, where
a
On Sun, 27 Nov 2016 21:19:16 +, Benedikt Ritter wrote:
[...]
You have asked for opinions - be prepared people don't agree with
you.
[...]
Just because it is supported doesn't mean it is a good idea.
I actually expected arguments as to why it would not be a good
idea.
You are right
On Sun, Nov 27, 2016 at 1:19 PM, Benedikt Ritter wrote:
> Hello Gilles,
>
> Gilles schrieb am So., 27. Nov. 2016 um
> 22:11 Uhr:
>
> > On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote:
> > > I think everything would be much easier to just maintain one version
> > > per
> > > repository. Bes
Hello Gilles,
Gilles schrieb am So., 27. Nov. 2016 um
22:11 Uhr:
> On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote:
> > I think everything would be much easier to just maintain one version
> > per
> > repository. Besides, it would get confusing having multiple git tags
> > or svn
> > tags
On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote:
I think everything would be much easier to just maintain one version
per
repository. Besides, it would get confusing having multiple git tags
or svn
tags for different component versions, especially if a repository
uses
short tag names that
I think everything would be much easier to just maintain one version per
repository. Besides, it would get confusing having multiple git tags or svn
tags for different component versions, especially if a repository uses
short tag names that only include the version number and not the component
name
I forgot to mention that it seems to me that this (a singly versions block of
code) is the fundamental "meaning" of what a repository is. I mean that in the
sense that if you want separate separately versioned components, that is a
direct argument for separate repositories.
With that said, I'm
I'm also in the "one-version per repository"-camp.
Benedikt
Stian Soiland-Reyes schrieb am So., 27. Nov. 2016 um
11:48 Uhr:
> I think Gilles' reasoning is sound for semantic versioning and releases, in
> line with OSGi principles. However I think that would be better suited in a
> large or ente
I think Gilles' reasoning is sound for semantic versioning and releases, in
line with OSGi principles. However I think that would be better suited in a
large or enterprise project with mainly internal usersnpf the libraries
that can play along, not in Apache Commons which are making general
availab
Gary Gregory wrote:
> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
> wrote:
>
>> Sorry, for me this is going down the wrong road. For me different
>> versions mean different components. Allowing multiple versions for
>> modules in one component will exactly open the can of worms Gilles
>> desc
My experience suggests that the "one repository, one version" rule works best.
This, however, does not solve the concern of allowing quick releases with
multiple simultaneous features.
This concern is better solved with feature branches. Mainline branch,
(“master”) must be releasable at any
On Sat, Nov 26, 2016 at 9:28 AM, Rob Tompkins wrote:
> I've always thought that versioning sat at a repository level. When you
> check out (or clone or whatever) code it feels counterintuitive to have
> several different potential versions floating around in what you just got.
> So I would argue
On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
wrote:
> Sorry, for me this is going down the wrong road. For me different versions
> mean different components. Allowing multiple versions for modules in one
> component will exactly open the can of worms Gilles described below. We had
> that alread
I've always thought that versioning sat at a repository level. When you check
out (or clone or whatever) code it feels counterintuitive to have several
different potential versions floating around in what you just got. So I would
argue for the general guideline of one repository, one overall ver
Sorry, for me this is going down the wrong road. For me different versions
mean different components. Allowing multiple versions for modules in one
component will exactly open the can of worms Gilles described below. We had
that already with Jakarta.
I still propose commons-rng-tools as separat
Hello.
As a follow-up of
http://markmail.org/message/jckbknphndecglns
and
http://markmail.org/message/f3g33kvevf52xohf
I summarize what I think should be allowed for versioning
modularized components of the "Commons" project.
Assume there are two modules in project "Commons ModProj":
commo
27 matches
Mail list logo
