Versiones principales frente a secundarias: explicación de software y SharePoint

By Mirko Peters · 2026-05-25 · Updated 2026-07-16

Compara las versiones principales y secundarias de SharePoint en cuanto a borradores, publicación, aprobaciones, visibilidad, historial de versiones, permisos, restauración y gobierno de documentos.

Automatically translated with AI from the original post. Read the English original

Entender las versiones principales y secundarias no es solo cosa de programadores o del equipo de TI: es importante para cualquiera que trabaje con sistemas digitales modernos. Tanto si lanzas software, actualizas bibliotecas de SharePoint o mantienes la gobernanza de Microsoft Teams, conocer la diferencia entre tipos de versión ayuda a que todos estén en la misma página.

Esta guía cubre los aspectos prácticos del control de versiones: explica las reglas, las buenas prácticas y por qué esto importa más allá de la jerga técnica. Verás cómo una gestión inteligente de las versiones conduce a actualizaciones más estables, a una mejor colaboración y a cambios más fluidos en toda la organización. Tanto los lectores de TI como los de negocio encontrarán orientación clara para gestionar las actualizaciones con confianza y claridad.

Introducción a los conceptos de versionado y a las versiones múltiples

Empecemos por lo básico: una «versión» es simplemente una etiqueta que indica en qué estado se encuentra un software, un documento o un sistema en un momento concreto. Estos números de versión ayudan a todos a seguir la pista de los cambios a lo largo del tiempo. Piensa en ellos como los puntos de control de una carretera: siempre sabes dónde te detuviste y qué ha cambiado desde entonces.

Ahora bien, destacan dos tipos principales de versiones: versiones principales y versiones secundarias. Una versión principal marca un hito importante, es decir, algo sustancial ha cambiado, como nuevas funciones o un cambio que no es compatible con versiones anteriores. Por otro lado, una versión secundaria suele indicar mejoras pequeñas e incrementales que se apoyan en lo que ya existe, a menudo de forma que no rompe lo que los usuarios ya están utilizando.

El versionado no es solo cosa del software. Plataformas como SharePoint utilizan el control de versiones para gestionar los cambios en documentos y listas, lo que facilita revisar el historial o restaurar borradores anteriores si es necesario. Unas buenas prácticas de versionado reducen el riesgo: si algo sale mal después de una actualización, sabes exactamente qué cambió. Y para las organizaciones, entender la diferencia entre tipos de versión significa actualizaciones más fluidas, una gobernanza más clara y menos sorpresas durante las transiciones.

Al dominar estos fundamentos, los equipos técnicos y las partes interesadas de negocio pueden tomar decisiones más acertadas. Tanto si planificas lanzamientos de software, gestionas los cambios en SharePoint como si despliegas actualizaciones en Microsoft 365, los conceptos sólidos de versionado son tu red de seguridad para gestionar riesgos y mantener a todos alineados.

Comparación de versiones secundarias y principales: ¿qué las diferencia?

La diferencia entre una versión principal y una secundaria es mucho más que un número: tiene que ver con el grado de impacto que puede tener cada actualización. Una versión principal suele representar un hito importante, con nuevas funciones relevantes, rediseños profundos o cambios que rompen la compatibilidad y obligan a los usuarios a adaptarse o a recibir formación. Cuando un software pasa de la versión 1.0 a la 2.0, por ejemplo, no es solo un cambio cosmético; normalmente implica una capacidad nueva significativa o un cambio que no funciona igual que antes.

Una versión secundaria, en cambio, es más bien un avance suave. Piensa en correcciones de errores, mejoras menores o funciones nuevas que no rompen nada. Pasar de la 1.2 a la 1.3 aporta valor, normalmente mejora la funcionalidad, pero rara vez altera el uso existente o las integraciones. Las versiones secundarias permiten que todo avance sin obligar a los usuarios a cambiar sus flujos de trabajo.

Los desencadenantes de una actualización principal pueden ser una nueva interfaz de usuario, un cambio que rompa las integraciones existentes o la eliminación de funciones antiguas. Las versiones secundarias, en cambio, se originan en adiciones compatibles con versiones anteriores: opciones extra, ajustes o mejoras de rendimiento que no alteran lo que ya funciona. En SharePoint, publicar un documento como versión principal significa que está oficialmente aprobado y visible para todos, mientras que las versiones secundarias permiten a los equipos colaborar y realizar ediciones que permanecen ocultas hasta que están listas para mostrarse.

Etiquetar claramente las versiones como principales o secundarias ayuda a planificar los despliegues y a cumplir la normativa, y avisa tanto a TI como a los usuarios finales de lo que pueden esperar. Las versiones principales pueden requerir nueva formación o comunicaciones, mientras que las secundarias pueden llegar con discreción y con muy poco revuelo. En definitiva, entender la diferencia entre ambas favorece la confianza de los usuarios, mantiene controlados los riesgos de compatibilidad y agiliza las estrategias de soporte y adopción.

Versionado semántico en el desarrollo de software

El control de versiones semántico, o SemVer, se ha convertido en el estándar de referencia para gestionar las versiones de software. Es mucho más que una convención de nombres: es una forma de establecer expectativas claras sobre lo que traerá cada nueva versión de un producto. Al estandarizar cómo se asignan e incrementan las versiones, SemVer permite ver de un vistazo si una actualización es una renovación que cambia las reglas del juego, una nueva funcionalidad segura o simplemente una corrección de errores.

La gran ventaja del control de versiones semántico es su previsibilidad. Si mantienes un software o dependes de bibliotecas externas, necesitas saber cuándo es seguro actualizar sin romper nada. Con SemVer, el número de versión te indica qué tipo de compatibilidad puedes esperar, lo que ayuda a evitar sorpresas desagradables y pesadillas con las dependencias.

En esta sección veremos qué significa realmente el control de versiones semántico, analizaremos la conocida especificación 2.0.0, destacaremos por qué tantos equipos confían en ella y mostraremos cómo ayuda a gestionar las APIs públicas y a retirar funcionalidades de forma ordenada. Si dominas este sistema, los equipos podrán colaborar de forma más eficaz y publicar actualizaciones con seguridad, sabiendo que están respaldadas por un historial de versiones claro y coherente.

Especificación de Control de Versiones Semántico 2.0.0 y formato de numeración

1. Formato del número de versión:Semantic Versioning utiliza el formato MAJOR.MINOR.PATCH (por ejemplo, 2.3.7). Cada número tiene una función:

• MAJOR—Incrementa este número cuando realices cambios incompatibles en la API u otros cambios importantes.
• MINOR—Incrementa este número cuando añadas funcionalidades de forma compatible con versiones anteriores.
• PATCH—Úsalo para correcciones compatibles con versiones anteriores, como la resolución de errores.

1. Identificadores de prelanzamiento:Si publicas algo antes de que sea oficialmente estable, añade al final un guion y una etiqueta. Por ejemplo, 2.3.7-beta o 2.4.0-rc.1. Esto indica que la versión no está lista para producción completa.
2. Metadatos de compilación:También puedes añadir información de compilación después de un signo +, como 2.3.7+20240605. Esto no afecta a la comparación de versiones, pero puede ayudar a rastrear compilaciones concretas.
3. Análisis sintáctico y reglas BNF:SemVer establece que solo se permiten enteros no negativos, y la cadena de versión completa sigue una gramática Backus–Naur clara que las máquinas pueden analizar. No se admiten números decimales: es una estructura estricta de tres partes.
4. Ejemplo real:Si una biblioteca pasa de 1.4.2 a 2.0.0, los desarrolladores saben al instante que hay cambios incompatibles. Si pasa de 1.4.2 a 1.5.0, es seguro actualizar para obtener nuevas funcionalidades. Un salto de 1.4.2 a 1.4.3 indica solo correcciones de errores.

¿Por qué usar el control de versiones semántico?

• Actualizaciones previsibles: Los equipos saben qué riesgo esperar con cada cambio de versión, lo que hace que las actualizaciones den menos miedo.
• Mejor gestión de dependencias: Los desarrolladores pueden definir reglas para aceptar solo versiones compatibles, lo que reduce el riesgo de que algo se rompa.
• Comunicación clara: Todos, tanto en TI como en negocio, pueden ver de un vistazo si una actualización es mayor, menor o una corrección, sin adivinanzas.
• Confianza y estabilidad: Los equipos y los usuarios son más propensos a actualizar sus sistemas cuando el versionado es fiable y transparente.

Cómo gestionar la retirada de funcionalidades y versionar las APIs públicas

1. Marca las funcionalidades como obsoletas antes de eliminarlas:Indica claramente las funcionalidades anticuadas como «obsoletas» en la documentación, las notas de la versión y las anotaciones del código. Avisa a los usuarios con antelación de que la funcionalidad desaparecerá en futuras versiones.
2. Comunica y establece plazos:Define plazos para la eliminación: anuncia los cambios incompatibles con varias versiones de antelación. Informar a los usuarios del calendario exacto para adaptarse reduce la frustración y las sorpresas.
3. Ofrece rutas de migración:Al retirar una funcionalidad, proporciona siempre alternativas o guías de migración para que los usuarios puedan pasar de la antigua de forma sencilla. Pueden incluir ejemplos de código, comparativas lado a lado o herramientas de migración automatizadas.
4. Incrementa la versión MAJOR en los cambios incompatibles:Si eliminas o alteras de forma significativa APIs públicas de un modo que rompe el uso existente, esto debe provocar siempre un incremento de la versión MAJOR según las reglas de SemVer. Así se avisa a todos los usuarios del riesgo y de la acción requerida.
5. Alinea con las hojas de ruta de producto:Planifica las retiradas y eliminaciones en sincronía con las hojas de ruta generales del producto. Marca estos hitos en los planes públicos y en los anuncios de versiones para que las partes interesadas estén informadas y se reduzca el pánico.
6. Supervisa y responde a los comentarios:Una vez publicados los cambios, recopila los comentarios de los usuarios y los informes de errores. Prepárate para revertir o aplicar una corrección urgente (hotfix) a los cambios que rompan funcionalidades si detectas problemas de adopción.

Control de versiones en SharePoint: listas, bibliotecas y la biblioteca de páginas

A diferencia del software tradicional, SharePoint lleva el control de versiones al mundo de los documentos, las listas y los espacios de colaboración de la empresa. Aquí, los controles de versión no solo se aplican al código: gestionan desde las ediciones de archivos hasta los cambios en las directivas de toda la organización. Con el control de versiones principal y secundario, SharePoint conserva un historial de cambios claro y garantiza que tu equipo siempre sepa qué está publicado y qué sigue en curso.

Las versiones principales en SharePoint suelen indicar que un documento se ha publicado o aprobado oficialmente, mientras que las versiones secundarias mantienen los ajustes y los borradores en privado hasta que están listos para verse. Si alguien necesita revertir una actualización errónea o auditar quién cambió qué, el control de versiones incorpora esa red de seguridad en la propia plataforma.

Aprenderás a habilitar estas funciones en bibliotecas de documentos y listas, a controlar el almacenamiento y la visibilidad de las versiones antiguas, y a vincular el control de versiones con los flujos de trabajo de aprobación y la configuración de permisos. Estas herramientas no solo protegen el contenido: también favorecen el cumplimiento normativo, la edición colaborativa y la transparencia que toda organización moderna necesita.

¿Te interesa saber cómo se compara el control de versiones de SharePoint con otras herramientas de Microsoft 365? Consulta esta comparativa sobre paneles de Teams frente a SharePoint, que muestra cómo cada plataforma se adapta a públicos y necesidades distintos.

Cómo habilitar las versiones secundarias y el control de versiones en listas y bibliotecas

1. Accede a la configuración de la biblioteca o la lista:Ve a tu sitio de SharePoint, abre la biblioteca de documentos o la lista que corresponda y selecciona «Configuración de biblioteca» o «Configuración de lista».
2. Busca la configuración de versiones:Haz clic en el vínculo «Configuración de control de versiones». Aquí es donde configuras todas las opciones de versiones.
3. Habilita las versiones principales y secundarias:Elige «Crear versiones principales y secundarias (borrador)». Así, los borradores se guardan en privado hasta que se publican como versiones principales.
4. Configura la aprobación de contenido:De manera opcional, activa la aprobación de contenido para que los cambios secundarios requieran revisión antes de hacerse visibles para todos. Es ideal para contenido sensible o para el cumplimiento normativo.
5. Guarda y aplica:Haz clic en «Aceptar» para guardar la configuración. El control de versiones secundario ya está activo, lo que ofrece un control de documentos más sólido y registros de auditoría.

Control de las versiones almacenadas y determinación de elementos borrador en SharePoint

• Directivas de retención de versiones:Limita el número de versiones almacenadas definiendo un máximo en la configuración de control de versiones. Así evitarás un crecimiento descontrolado del almacenamiento.
• Permisos de elementos borrador:Decide quién puede ver las versiones secundarias (borradores). Normalmente, solo los usuarios con permisos de «Editar» o grupos específicos, para mantener en privado las ediciones sensibles hasta su publicación.
• Revisa el historial de versiones:Los usuarios pueden consultar el historial de versiones para seguir los cambios, restaurar versiones anteriores o ver quién realizó determinadas ediciones, lo que facilita las auditorías de cumplimiento y la resolución de problemas.
• Permisos de biblioteca:Asigna permisos detallados por usuario o grupo para controlar quién puede editar, eliminar o restaurar versiones. Es clave en equipos regulados o con contenido confidencial.
• Consejos de gestión de contenido:Limpia los borradores antiguos o innecesarios y configura alertas de cambios de versión para gestionar y supervisar las bibliotecas importantes sin que se llenen de desorden.

Aprobación de contenido, registro de versiones de archivos y registro obligatorio en bibliotecas

1. Configura la aprobación de contenido:Habilita la aprobación de contenido en la configuración de versiones para exigir una revisión antes de publicar versiones secundarias o principales. Se utiliza en documentos oficiales o páginas que necesitan supervisión.
2. Registro y devolución de archivos:Exige que los archivos se registren (check out) antes de editarlos, de modo que solo un usuario a la vez realice cambios. Al devolverlos (check in) se crea un borrador (versión secundaria), lo que reduce las sobrescrituras accidentales.
3. Registro obligatorio:Obliga a los usuarios a registrar los documentos antes de realizar cualquier edición. Esto añade un nivel más de control, es ideal para entornos legales o regulados y evita confusiones por ediciones simultáneas.
4. Orden de creación de versiones:Cada devolución, ya sea secundaria o principal, crea una nueva versión, lo que ayuda a llevar un historial detallado de cambios y aprobaciones de cada documento.
5. Casos de uso de calidad y cumplimiento: Combina flujos de aprobación, control de versiones y registro de salida (check-out) para procedimientos sensibles, como la publicación de cambios en directivas, informes financieros o documentos legales, de modo que nada pase desapercibido ni sin aprobar.

Esquemas de numeración de versiones: enfoques técnicos y ejemplos reales de software

Los números de versión no se eligen al azar: existen sistemas reales para elegirlos que van mucho más allá de «sumar uno a la última versión». Ya sea una secuencia numérica, un esquema basado en el calendario o el conocido control de versiones semántico, todos estos modelos sirven para dar estructura y significado al proceso de actualización.

Distintas industrias y proyectos optan por esquemas diferentes. A veces verás una versión como 2024.06 (basada en el calendario), otras veces simplemente 105 (secuencial) y, en otras ocasiones, una versión más descriptiva como 1.2.3 (semántica). Cada una tiene su lugar según cómo evolucionen el software, los documentos o las plataformas, cómo se gestione el cumplimiento normativo y con qué frecuencia se publiquen las versiones.

A continuación, veremos los modelos de versionado más comunes y ejemplos reales de gigantes tecnológicos como Apple, Microsoft y el proyecto de código abierto Python. Si observas cómo lo hacen los expertos, tendrás una idea clara de lo que funcionará en tus propios proyectos, ya sea que busques claridad, cumplimiento o un poco de ambos.

Esquemas de versionado habituales: identificadores secuenciales e identificadores de fecha de publicación

• Control de versiones semántico (SemVer): Usa MAJOR.MINOR.PATCH (por ejemplo, 3.1.4). Aporta claridad sobre la compatibilidad y los cambios. Ideal para proyectos de código abierto y API.
• Basado en fechas (CalVer): Usa fechas como AAAA.MM (por ejemplo, 2024.06). Es habitual en productos con publicaciones periódicas programadas, como Ubuntu Linux.
• Numeración secuencial: Simplemente aumenta el contador (por ejemplo, 101 → 102). Se usa en compilaciones internas o en sistemas donde solo importa el orden.
• Modelos combinados: Algunas organizaciones combinan esquemas, como el semántico para las publicaciones orientadas al cliente y el secuencial para las compilaciones internas.

Ejemplos de software: cómo gestionan las versiones Apple, Microsoft Windows y Python

• Apple macOS/iOS: Las grandes funciones nuevas o los rediseños provocan saltos de versión mayores (por ejemplo, iOS 15 → iOS 16), mientras que los parches incrementales corrigen mejoras menores o errores.
• Microsoft Windows: Windows usa versiones principales (como Windows 10 y 11), pero también subversiones con fecha (por ejemplo, 21H2) para las actualizaciones importantes y los parches.
• Python: Cada versión principal (2, 3) introduce cambios de compatibilidad, las subversiones (por ejemplo, 3.11) añaden funciones y las versiones de parche corrigen errores. Es muy claro en cuanto al impacto de cada cambio.
• Proyectos de código abierto: Proyectos como Node.js y Linux combinan el esquema semántico con el basado en fechas para las ramas o las versiones LTS, equilibrando estabilidad y calendario.

Versionado avanzado: versiones preliminares, actualización de dependencias y expresiones regulares

No todas las versiones están listas para producción: algunas siguen en fase «alpha», «beta» o «release candidate» (RC). Etiquetar estas versiones como preliminares ayuda a desarrolladores y usuarios a saber qué es seguro probar y qué está listo para producción. Gestionar estas versiones con inteligencia implica aplicar buenas prácticas para la actualización de dependencias y contar con reglas sólidas que detecten errores en las cadenas de versión.

En el mundo DevOps actual, automatizado, los números de versión suelen asignarlos scripts, canalizaciones o mensajes de commit, no siempre a mano. Las expresiones regulares (regex) pueden garantizar que los formatos de versión sean válidos y coherentes en todos los sistemas, lo que reduce los errores de publicación antes de que lleguen a los clientes.

Veamos cómo usar las etiquetas de versiones preliminares, configurar comprobaciones de validación y actualizar las dependencias sin problemas. Si buscas que tu proceso de publicación sea más limpio, reducir las actualizaciones que fallan o mantener sincronizados proyectos complejos, estas herramientas avanzadas te van a encantar.

Uso de versiones preliminares y expresiones regulares sugeridas para la validación de versiones

• Etiquetas de versión preliminar: Usa etiquetas como -alpha, -beta o -rc.1 para marcar las versiones en fase de prueba o con funciones incompletas. Así, son los probadores, y no los usuarios finales, quienes obtienen las actualizaciones adecuadas.
• Validación de versiones: Aplica expresiones regulares (regex) como ^(\d+)\.(\d+)\.(\d+)(?:-[\w\.]+)?(?:\+[\w\.]+)?$ para confirmar formatos como 1.2.3-beta+exp.sha1.
• Coherencia en CI/CD: Automatiza las comprobaciones de versión en las canalizaciones de compilación para bloquear las publicaciones que no sigan tu estándar. Así se reducen los saltos accidentales y la confusión.
• Actualizaciones seguras de dependencias: Usa rangos de versiones y coincidencias estrictas con expresiones regulares en la gestión de paquetes para evitar que versiones preliminares inestables o no coincidentes lleguen a sistemas críticos.

Información complementaria, licencias y puntos clave sobre la importancia de las versiones

Para terminar, recuerda que la forma en que gestionas las versiones principales y secundarias no es solo un detalle técnico: ayuda a generar confianza en los usuarios, a gestionar riesgos y a proteger la reputación de tu organización. Hacer bien el versionado es una buena forma de comunicar, y te ahorra dolores de cabeza más adelante cuando las cosas cambian. Un versionado claro facilita el seguimiento y la gestión de las actualizaciones, tanto para tu equipo de TI como para los usuarios de negocio.

Muchos de los estándares de versionado de software que existen, como Semantic Versioning (SemVer), son abiertos y impulsados por la comunidad. La propia especificación SemVer se publica bajo la licencia Creative Commons CC BY 3.0, que te permite usarla y adaptarla según necesites en tus proyectos, siempre que reconozcas su autoría. Antes de incorporar herramientas o especificaciones a tu flujo de trabajo, revisa siempre sus licencias.

Si quieres mantener tus conocimientos actualizados, busca foros de la comunidad, debates en GitHub o la documentación de Microsoft Learn sobre el control de versiones en SharePoint. Siempre hay mucha gente dispuesta a hablar de buenas prácticas. Los comentarios, ya sean las reacciones de los usuarios ante una actualización importante o las ideas de los desarrolladores sobre la automatización, deberían alimentar tu estrategia de versionado para mejorarla de forma continua.

En resumen: gestiona las versiones principales y secundarias con intención. Haz que las actualizaciones sean claras para todos, especialmente para quienes no pertenecen a TI. Aprovecha los estándares abiertos con criterio y no dudes en consultar a la comunidad para obtener nuevas ideas. Un versionado bien pensado es mucho más que números: se trata de confianza, control y un camino sin sobresaltos en cada paso.

También te puede interesar

Entender las diferencias entre las versiones principales y secundarias de SharePoint ayuda a los equipos a separar los borradores del contenido publicado y a conectar las decisiones de edición, aprobación, visibilidad y retención. Estos episodios explican el sistema de documentos que los rodea:

• Solucionar el caos de documentos entre Dynamics 365 y SharePoint — Descubre cómo la arquitectura de documentos, las integraciones, los permisos y las decisiones sobre el ciclo de vida influyen en una gestión de contenido escalable.
• Frenar la expansión descontrolada de SharePoint con gobierno de datos y automatización — Explora cómo el ciclo de vida, la propiedad, la automatización y el gobierno del contenido evitan la expansión descontrolada de SharePoint a largo plazo.
• Auditar el acceso a los datos de Microsoft 365 antes de implementar Copilot — Descubre cómo los permisos, la propiedad, la sobreexposición y los límites de los datos afectan a la seguridad y a la preparación para la IA.
• Cómo cerrar la brecha de metadatos de SharePoint para la IA y el gobierno — Aprende cómo la clasificación y los metadatos facilitan la recuperación, el gobierno y el uso de los documentos con IA.