-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start work on collection:<name> packages #72
Comments
How should we rename PeerDB then? |
Something like that could definitely work. As I mentioned, discussions are needed around which packages should be integrated into the namespace and under what name they will be integrated. 😄 edit: The same goes for my packages ofc |
This sounds like a good idea. |
Count me in. Also, @rclai your fork of collection-hooks that uses your collection-extensions is a great idea -- definitely in for that too. |
@matb33 I wanted to give you a pull request (even after your tests have passed under it and has been working fine for me), but I'm kind of scared to and don't want other people's stuff to break because of me lol, but maybe this time I will (after I get it synced upstream). |
Nice to see that there's some interest in this 👍 I'm rewriting and renaming I'm pubishing a new package It's a shame that Meteor don't have support for renaming packages yet. But maybe it's possible to ask MDG/Percolate Studio to move all the meta data surrounding the packages to the new names. |
I like this idea. Last night @SachaG and I were discussing the need for more of a committee/organization structure around some of the related and oft-used packages (but without giving up too much author control). This could be a good step in that direction for collection packages. My biggest worry is the transition/renaming. If @zimme can come up with a foolproof plan for that, I'm in. I think MDG's approach to renames of core packages in the past has been keeping the old packages around as empty "imply" packages. |
Yeah, the renaming/moving is quite a concern. I'll keep you guys updated on the renaming of I've already used pretty much the same method when I've integrated Meteor support into the libraries I've wrapped before. With these packages I just published a new version which used and implied the new official packages, updated the READMEs and descriptions to inform developers that they've been deprecated. Then I just The big difference from those packages are that I didn't care for the metadata around the packages and here we do. |
Sounds like a great idea. And I'm happy to take PRs to implement these packages in Telescope, that can be a good way to bring more attention to them. |
So I was thinking of renaming PeerDB then to |
So I just released If all goes well with this rename, hopefully people will be more inclined to join this namespace. |
@mitar, unless there are some other "big" packages which do the same thing as peerdb does then I'm all for having peerdb become |
I think of the |
That is a valid point @aldeed But where would we draw the line? |
I'm actually not sold on this idea as it seems to conflict with/break the intention of the author/organisation naming convention by now depicting a kind of ‘category’ rather than an organisation, which then raises a bunch of questions. It feels like it's a kind of side-step, given the packaging servers lack of categorisation. |
@dburles That's something I hadn't thought about and it's a good point. I'm open to maybe do this under som other namespace, which is more like an organisation in that sense. |
Ok, so from the discussion here and how my effort with renaming When Meteor have support for renaming packages for real the discussion about using a common namespace for our packages might be valid again. But I think we who maintain these "simple" collection packages which focuses on one thing per package should try and work together as much as possible. I suggest we use this issue tracker here under the I'll close this issue in about one week unless the discussion have resurrected. |
Hey
I've been working with my packages lately and this got me thinking I wanna start renaming some of my packages and I thought about using the
collection
namespace.@dandv: Would you mind adding me to the
colllection
organization as I saw that you were one of the maintainers of it.This is what I have in mind for my own packages:
zimme:collection-behaviours
->collection:behaviours
zimme:collection-timestampable
->collection:timestamp
zimme:collection-softremovable
->collection:softremove
My upcoming work for archiving docs would go into
collection:archive
.I would also like to ask a couple of the other guys if they're willing to join my effort and provide their functionality under the
collectiton
namespace.@rclai
lai:collection-extensions
->collection:extensions
?Maybe even
collection:core
? (this needs more discussion)@mattb33
matb33:collection-hooks
->collection:hooks
?@dburles
dburles:collection-helpers
->collection:helpers
?dburles:mongo-collection-instances
->collection:instances
?My thoughts around this is that we all try and rely on each others work as much as possible.
I know @dburles already accepted a PR to use
lai:collection-extensions
, which is nice.I've also seen @lai doing some work on making @matb33's
matb33:collection-hooks
rely onlai:collection-extensions
.I myself would rely on his package for
collection:behaviours
to have the option to automatically add the behaviours to all the collections instead of just manually attaching the behaviours to specific collections, but I feel it should be a choice. There will be a need for supporting an exception list though.In my packages for specific behaviours like
collection:softremove
I already rely onmatb33:collection-hooks
.We would all be responsible for our own packages under the namespace, but I believe the benefits of us all working more close together are great.
We would make the decision on which "new" packages we would accept into the namespace.
Examples:
collection:archive
I wouldn't publish the work under the namespace until a majority of us feels its ok to do so.I also think we could work out of either the
MeteorCommunity
orMeteorPackaging
organization on Github.Another alternative is to use one of
MeteorCollection
,MeteorCollections
orMeteorCollective
organization which I've just registered. I will remove the unused organizations once a decision has been made.Who knows, maybe @aldeed want to join us with his
aldeed:collection2
package under the namecollection:validation
or something in that direction.I feel that we all could benefit from such an endeavour.
What do you guys think? Do you feel it's worth it?
The text was updated successfully, but these errors were encountered: