Change:
<ins> { lib, stdenv, fetchFromGitHub, fetchurl, gtk2, glib, pkg-config, unzip, ncurses, zip }: stdenv.mkDerivation rec { version = "11.3"; pname = "textadept"; nativeBuildInputs = [ pkg-config unzip zip ]; buildInputs = [ gtk2 ncurses glib ]; enableParallelBuilding = true; src = fetchFromGitHub { name = "textadept11"; owner = "orbitalquark"; repo = "textadept"; rev = "textadept_${version}"; sha256 = "sha256-C7J/Qr/58hLbyw39R+GU4wot1gbAXf51Cv6KGk3kg30="; }; preConfigure = lib.concatStringsSep "n" (lib.mapAttrsToList (name: params: "ln -s ${fetchurl params} $PWD/src/${name}" ) (import ./deps.nix)) + '' cd src make deps ''; postBuild = '' make curses ''; preInstall = '' mkdir -p $out/share/applications mkdir -p $out/share/pixmaps ''; postInstall = '' make curses install PREFIX=$out MAKECMDGOALS=curses ''; makeFlags = [ "PREFIX=$(out)" "WGET=true" "PIXMAPS_DIR=$(out)/share/pixmaps" ]; meta = with lib; { description = "An extensible text editor based on Scintilla with Lua scripting."; homepage = "http://foicica.com/textadept"; license = licenses.mit; maintainers = with maintainers; [ raskin mirrexagon patricksjackson ]; platforms = platforms.linux; }; } </ins>

Discussion:
I stumbled across the packages the other day, and after investigating a bit I think they should be merged. Is there a procedure or set of best practices for merging two packages? There are 2 separate packages: , which is located in , and is on textadept v10.8. , which is located in , and is at the current release of textadept, v11.3. I was the one who recently pinned/updated these packages, but previous updates for version 11 have gone into with no backporting to , which is why I kept on v10. AFAICT, there is no reason these should be separate packages. They were split in because someone wanted access to the v11 beta, and the changes have carried forward since. There seems to be no breaking change or issue between v10 and v11.
If 11 is stable and there is no need anymore for 10 we should drop then and make 11 the default attribute.
Hi, So, I'm the one who wanted to try the beta :sweatsmile: Let me describe my point: 10 and v11 are two major versions - they have . So some plugins (and so on) from . was the first time I contributed to - and I still do not know when to migrate a package from one major version to the next. So, please, tell me more about this topic! :sweatsmile: I, personally, don't have any problems to use old versions like so: As a sidenote: I've tried nixos-22.05 ~a week ago and it fails to build on Textadept. Something with QScintilla - does it builds for you,
Hi I am new to contributing around here as well so I'm figuring this out as I go along :) I fixed the build for both Textadept versions in and , and that was how I noticed this oddity with the package names. With the package names, it generally makes the most sense to have refer to the current latest version of the project (11.3 at the moment). If there's good reason to keep the old version around then maybe we want to go back and add a that is pinned to stay on v10.8, as per the conventions in .

The wiki pages talking about incompatible plugins is over a year old, so I assumed that the plugins were mostly updated for v11 and that v10 was no longer used. But it seems that I may have been wrong. You are more familiar with using this program than I am. If you think it's necessary to keep v10 around then I'll support it. With Nix, there are of course ways to keep using prior versions, but it seems like there may be a reason that users would choose to continue using that specific version.
hi again! Sorry it took so long to answer. Thanks for versioning conventions, now I know :sweat_smile: But I've started using Textadept from v11 and cannot be sure for v10 users :/ From : I get the versioning conventions, but how to decide when to leave older major version? ... differ significantly in functionality seems to be a little unclear. Maybe there is some discussion or voting process? Not saying we should start it in this case though, just curious. If you ask me, I agree to leave only v11 (as just package). Also, thank you for maintaining the package :wink: