You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should consolidate forks. New features and fixes are lately being added by various people on separate forks but they do not get merged on time or consistently. As a results we end up with duplication of work/fixes and most importantly with multiple packages on atom.io. I believe this is very confusing for end-users and could be easily avoided.
The majority of forks belong to two developement branches/streams. These are starting from @sveale 1.8.24 and have resulted in the following "major" versions (different packages on atom.io)
@sveale 1.9.0:
The original development stream that lately only has minor fixes
@duxet 3.1.0:
This branch has @duxet's and my features and extensions from last year. These are mainly around create file/folder, cut/paste, delete and sftp handler ... handling :)
@newinnovations 2.1.0:
adding keyboard shortcuts, fixes for atom 1.19 and renaming the package
@urban-1 devel:
My latest and greatly buggy probably version adding a tree-view like on top of the remote folder view... (it is not released yet but it is the reason I am raising this issue)
Merging these branches should be fairly straight forward, however, due to the fact that the package name is being used in the atom settings the above branches have three different names (remote-edit, remote-edit2, remote-edit-ni). I propose the following:
@sveale : If you want to maintain the original repo, that would be ideal! I would suggest tho that you add the most active users (the ones above) as collaborators so we can merge, manage versioning/releases and close issues. I understand that time is limited (that goes for us too) so the more the merrier in that sense (make the project responsive)
@duxet / @newinnovations: If @sveale prefers to keep the official repo clean and not add new features, I suggest that we do the same on @duxet's repo and be added as collaborators
My only concern is releasing on atom.io - I have never done that and I don't know what is involved, if multiple developers can release or if a single person should be responsible for this...
Please let me know what your views are on this, since I really don't want to create Yet Another Remote-Edit package (maybe named atom-yare :) - just discovered the word )!
Cheers,
Andreas
The text was updated successfully, but these errors were encountered:
Hi all
I think we should consolidate forks. New features and fixes are lately being added by various people on separate forks but they do not get merged on time or consistently. As a results we end up with duplication of work/fixes and most importantly with multiple packages on atom.io. I believe this is very confusing for end-users and could be easily avoided.
The majority of forks belong to two developement branches/streams. These are starting from @sveale 1.8.24 and have resulted in the following "major" versions (different packages on atom.io)
The original development stream that lately only has minor fixes
This branch has @duxet's and my features and extensions from last year. These are mainly around create file/folder, cut/paste, delete and
sftp
handler ... handling :)adding keyboard shortcuts, fixes for atom 1.19 and renaming the package
My latest and greatly buggy probably version adding a tree-view like on top of the remote folder view... (it is not released yet but it is the reason I am raising this issue)
Merging these branches should be fairly straight forward, however, due to the fact that the package name is being used in the atom settings the above branches have three different names (
remote-edit
,remote-edit2
,remote-edit-ni
). I propose the following:@sveale : If you want to maintain the original repo, that would be ideal! I would suggest tho that you add the most active users (the ones above) as collaborators so we can merge, manage versioning/releases and close issues. I understand that time is limited (that goes for us too) so the more the merrier in that sense (make the project responsive)
@duxet / @newinnovations: If @sveale prefers to keep the official repo clean and not add new features, I suggest that we do the same on @duxet's repo and be added as collaborators
My only concern is releasing on atom.io - I have never done that and I don't know what is involved, if multiple developers can release or if a single person should be responsible for this...
Please let me know what your views are on this, since I really don't want to create Yet Another
Remote-Edit
package (maybe namedatom-yare
:) - just discovered the word )!Cheers,
Andreas
The text was updated successfully, but these errors were encountered: