1.0, 1.0.0, 1.0.0.RELEASE is IMHO a matter of personal taste, but I'm fine with
1.0 too :) should I push the pax-web version to 1.0? I think it is stable enough
for this step...
kind regards
On Tue, Oct 26, 2010 at 08:26:29AM +0800, Niclas Hedhman wrote:
> On Mon, Oct 25, 2010 at 11:20 AM, Andrea
On Mon, Oct 25, 2010 at 11:20 AM, Andreas Pieber wrote:
> [2] Describes the release process of ops4j proejcts. The following point's I'm
> not sure about:
>
> *) [2] makes difference between releases <1.0 and >=1.0 Is this really of
> relevance? IMHO all artifacts should be located at mvn central
Actually, feel free to go ahead, pax-web does not really depend on pax-url,
so it's not worth holding and pax-url has a new module based on aether which
seems to not be ready to be shipped.
I have some infos about releasing from github though.
Here is a patch I've used locally on org.ops4j.pax.ur
FWIW, I'm playing with the maven release plugin and git, so i'll give a
heads up on how to actually do a release on github ...
On Mon, Oct 25, 2010 at 10:56, Guillaume Nodet wrote:
> I'm planning to release pax-url later today or tomorrow, so if you have any
> problem with the current state, ju
I'm planning to release pax-url later today or tomorrow, so if you have any
problem with the current state, just shout quickly !
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
___
Add an environment option to pax-url-war to add optional package imports on
pax-logging-api packages
Key: PAXURL-87
URL: http://issues.ops4j.org/browse/PAXURL-87
sounds great, thank you
On Mon, Oct 25, 2010 at 09:59:57AM +0200, Guillaume Nodet wrote:
>I'm doing it right now, so if there's no objection to release pax-url,
>I can cut a release today or tomorrow.
>
>On Mon, Oct 25, 2010 at 09:38, Andreas Pieber <[1]anpie...@gmail.com>
>wrote:
I'm doing it right now, so if there's no objection to release pax-url, I can
cut a release today or tomorrow.
On Mon, Oct 25, 2010 at 09:38, Andreas Pieber wrote:
> When do you like to implement the changes? I mean, after I've pushed the
> snapshots I can wait, but nevertheless I prefere minor f
When do you like to implement the changes? I mean, after I've pushed the
snapshots I can wait, but nevertheless I prefere minor frequent releases above
huge and rare ones. I've no problem cutting another release (pax-web-0.8.1) in
two or three weeks...
kind regards
On Mon, Oct 25, 2010 at 08:15:
[
http://issues.ops4j.org/browse/PAXURL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613#action_13613
]
Andreas Pieber commented on PAXURL-86:
--
I've granted you pull requests to the repos. still following
+1
On Mon, Oct 25, 2010 at 9:21 AM, Andreas Pieber wrote:
> Any other opinions? Otherwise I'll push a snapshot by hand tonight (If I get
> the necessary rights
> granted by sonatype (issue already created) by then :))
>
> On Mon, Oct 25, 2010 at 09:21:31AM +0200, Peter Neubauer wrote:
>> Well,
>
Any other opinions? Otherwise I'll push a snapshot by hand tonight (If I get
the necessary rights
granted by sonatype (issue already created) by then :))
On Mon, Oct 25, 2010 at 09:21:31AM +0200, Peter Neubauer wrote:
> Well,
> I am fine with Sonatypes repos, less for us to maintain and more
> of
With hudson i could also tell some more things about integrating with
git. Not that we want to change the entire infrastructure .. We could
also just build the current master with bamboo on each push.
While commits are much more fine grained (yet they should not break
things imho) pushes to remote
Of all infrastructure components the most unimportant decision is which CI to
take (as long as there is one and it works :))
The most important point in this choice is that the administration of the
server
is easy for the administrators; Therefore (IMO) the choice is completely up to
you :)
ki
Well,
I am fine with Sonatypes repos, less for us to maintain and more
official to download from :)
/peter
On Mon, Oct 25, 2010 at 9:14 AM, Andreas Pieber wrote:
> while a build server will help a lot creating snapshots automatically I really
> need them anyhow on a server to be used in other pr
while a build server will help a lot creating snapshots automatically I really
need them anyhow on a server to be used in other projects (I think the karaf
team also requires them :)) I can simply deploy them by hand, but to ops4j's own
snapshot repositories or to the sonatype snapshot repositories
Or,
we could migrate our build system to Hudson, if Jira and SVN are going
to be migrated to GIT?
/peter
On Mon, Oct 25, 2010 at 9:13 AM, Guillaume Nodet wrote:
> At FuseSource, we came up with a little project to automatically generate
> the job descriptions for hudson:
> http://github.com/fu
At FuseSource, we came up with a little project to automatically generate
the job descriptions for hudson:
http://github.com/fusesource/hudsongen
Maybe the idea can be used for bamboo at well, just an idea ...
On Mon, Oct 25, 2010 at 09:09, Peter Neubauer wrote:
> Yup,
> I am imagining running
Yup,
I am imagining running ci only on the master branch. Just need to find
the time to update Bamboo...
/peter
On Mon, Oct 25, 2010 at 4:58 AM, Andreas Pieber wrote:
> Hey,
>
> In one of the last threads we've talked about CI for github. One
> question/suggestion in this context. It's typical f
19 matches
Mail list logo