Am 09.11.2013 18:18, schrieb evilrat:
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:
Is it possible to add a feature to sort the view by the added date of
a package (rather than just updated/name sorting)? Sometimes I'd like
to see which packages are new in the registry.
Would be nice if you could subscribe to a daily/weekly mail of the new
/updated packages .
On 10 Nov 2013 10:25, Sönke Ludwig slud...@outerproduct.org wrote:
Am 09.11.2013 18:18, schrieb evilrat:
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:
Is it possible to add a
On 11/10/13, Sönke Ludwig slud...@outerproduct.org wrote:
I've also thought about that in the past days, shouldn't be difficult to
add (an RSS feed could also be interesting).
I didn't want to appear needy, but yes an RSS feed would be awesome.
On 10/16/13, Sönke Ludwig slud...@outerproduct.org wrote:
The DUB package registry [1] has finally gained support for the text and
category based search of packages.
Is it possible to add a feature to sort the view by the added date of
a package (rather than just updated/name sorting)?
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic
wrote:
Is it possible to add a feature to sort the view by the added
date of
a package (rather than just updated/name sorting)? Sometimes
I'd like
to see which packages are new in the registry.
that would be really useful. who
code.dlang.org
Does we should have cats? maybe the organization by tags is
better?
Am 18.10.2013 08:47, schrieb Suliman:
code.dlang.org
Does we should have cats? maybe the organization by tags is better?
You mean like a flat list of tags?
Currently it's something like hierarchical tags. Each package can have
multiple categories, and the specific categories, as well as the
Am 17.10.2013 20:25, schrieb Tourist:
On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig wrote:
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard
On Friday, 18 October 2013 at 10:23:20 UTC, Sönke Ludwig wrote:
Am 17.10.2013 20:25, schrieb Tourist:
On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig
wrote:
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for
the text and
category
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
description and license present to be published. The
license field has to be set according to the
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
description and license present to be published. The
On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote:
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig
wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the
Am 17.10.2013 12:14, schrieb ilya-stromberg:
Add abbility to add the array with licenses:
license: [BSL-1.0, AFL-3.0, public domain]
I think it's better than
license: BSL-1.0 or AFL-3.0 or public domain
There will still be the need to specify or later, so this will only
make it partially more
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be MPL-2.0 and Apache-1.0 instead of or.
This is something that happens quite frequently when code is
taken from multiple projects or when the license
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be MPL-2.0 and Apache-1.0 instead of or.
This is something that happens quite
Am 17.10.2013 13:42, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product is
licensed under multiple licenses that must _all_ apply? That would
basically be MPL-2.0 and Apache-1.0 instead of or.
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both licenses need to be obeyed when using the package. If
those licenses are incompatible, that's a problem of the
package combining them - it's basically unusable
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I mean like a
page saying that my package was
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package. If those licenses
are incompatible, that's a problem of the
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
Personally I think it would be better if we had a dub publish
command, which would then error back if the server rejects the
package, rather than make this whole process automated based on
searching github (I assume this is how the dub server works
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I
On Thursday, 17 October 2013 at 12:27:02 UTC, Sönke Ludwig wrote:
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig
wrote:
If you have per-file differences, then this in fact means
that both
licenses need to be obeyed when using the
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it just
needs a very small HTTP API that can be
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing packages
to be updated: All packages must now have the fields description and
license present to be published. The license field has to be set
according to the specification [1]. All existing
Am 17.10.2013 15:26, schrieb Jacob Carlborg:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that
don't share any
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing
packages
to be updated: All packages must now have the fields
description and
license present to be published. The license
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it
The only license JSON that looks valid is the string. Simple bracketing
will suffice for complex licenses.
On 17 Oct 2013 16:05, Sönke Ludwig slud...@outerproduct.org wrote:
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets,
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the main/super package, in regards to licensing?
--
/Jacob
On 2013-10-17 15:53, Sönke Ludwig wrote:
Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public
License).
Cool, thanks.
--
/Jacob Carlborg
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the
Am 17.10.2013 17:02, schrieb Sönke Ludwig:
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard library candidate modules, as has been suggested recently.
If you already have any registered packages,
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard library candidate modules, as has been suggested recently.
If you already have any registered packages, please log in and add the
proper
On Wednesday, 16 October 2013 at 19:01:45 UTC, Sönke Ludwig wrote:
If you already have any registered packages, please log in and
add the proper categories to each of them (My packages -
click on package name). Should there be no exact category
match, and that specific category is likely to
On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:
Great! But I think the eloty categories must go until needed.
I meant empty.
Am 16.10.2013 21:24, schrieb ponce:
On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:
Great! But I think the eloty categories must go until needed.
I meant empty.
https://github.com/rejectedsoftware/dub-registry/issues/21
On 10/16/13, Sönke Ludwig slud...@outerproduct.org wrote:
It's still all a little rough around the edges. Any bugs can be reported
on the issue tracker [3] or discussed in the forum [4].
[1]: http://code.dlang.org
[2]:
Am 16.10.2013 21:58, schrieb Andrej Mitrovic:
On 10/16/13, Sönke Ludwig slud...@outerproduct.org wrote:
It's still all a little rough around the edges. Any bugs can be reported
on the issue tracker [3] or discussed in the forum [4].
[1]: http://code.dlang.org
[2]:
40 matches
Mail list logo
